----MESSAGE-BEGIN---- <1986050101390000> Mail-From: STJOHNS created at 1-May-86 08:40:20 Date: 1 May 1986 08:39-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: X.400 over TCP-IP? From: Mike StJohns To: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA] 1-May-86 08:39:12.STJOHNS> Is there anyone out there running X.400 mail above TCP/IP? Please resond direct to me, I'll summarize for the list. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050103255500> Received: from sri-med by SRI-NIC.ARPA with TCP; Thu 1 May 86 10:31:14-PDT Received: by sri-med at Thu, 1 May 86 10:25:55 pdt Date: Thu, 1 May 86 10:25:55 pdt From: Andy Poggio Message-Id: <8605011725.AA06138@sri-med> To: Mike StJohns Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: X.400 over TCP-IP? In-Reply-To: Your message of 1 May 1986 08:39-PDT. <[SRI-NIC.ARPA] 1-May-86 08:39:12.STJOHNS> Mike, I know that BBN is working on one and we at ISTC have toyed with the idea. I am very interested in any other responses you receive. Please let me know... --Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050103381000> Received: from NRTC-GREMLIN.NORTHROP.COM by SRI-NIC.ARPA with TCP; Thu 1 May 86 16:58:22-PDT Received: from localhost by NRTC-GREMLIN.NORTHROP.COM id a006045; 1 May 86 16:58 PDT To: Andy Poggio cc: Mike StJohns , tcp-ip@sri-nic.ARPA reply-to: tcp-ip@sri-nic.ARPA Subject: Re: X.400 over TCP-IP? In-reply-to: Your message of Thu, 01 May 86 10:25:55 PDT. <8605011725.AA06138@sri-med> Date: Thu, 01 May 86 16:58:10 -0800 Message-ID: <6038.515375890@nrtc-gremlin> From: Marshall Rose The big problem though is what goes between TCP-IP and X.400. Where's the session and presentation stuff? This is what partially motivated rfc983 - the iso/ccitt folks are spending the majority of their time arguing about addressing, etc. (in general, things that got solved fairly well 5 years ago!), and much less work is being done on the application stuff. Since all our previous experience tells us that doing the higher-level stuff is at least as hard as the lower-level stuff, if you're doing iso/ccitt applications, the rfc983 approach is a big win. (that bit of soap-boxing aside,) I know that the EAN system, originally from University of British Columbia, and now from Sydney Development Corporation has a TCP/IP interface. John Demco (demco@ubc.csnet) is one of the principle gurus at UBC. Looking at the NIC's HOST.TXT, I note that BBN-DIAMOND advertises TCP/X400 in addition to TCP/MPM. I've been meaning to ask the Diamond wizards about that, but haven't gotten around to it. If ISTC also has something, I'd like to hear more. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050108382000> Received: from BLUE.RUTGERS.EDU by SRI-NIC.ARPA with TCP; Thu 1 May 86 09:39:03-PDT Date: 1 May 86 12:38:20 EDT From: Ross Patterson Subject: Re: DEC-IBM connection To: 1017518%MCMASTER.BITNET@WISCVM.WISC.EDU cc: PATTERSON@BLUE.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "1017518%MCMASTER.BITNET@WISCVM.WISC.EDU" of 30 Apr 86 09:55:00 EDT Message-ID: <12203247084.42.PATTERSON@BLUE.RUTGERS.EDU> Joanne, If you are running MVS on the IBM system, you may want to consider using UCLA's Arpanet Control Program (ACP) software to drive an ACC IF/370E Ethernet adapter. The IF/370E seems to work well, and the UCLA code required no changes to support it (in fact, UCLA is considering buying an IF/370E also.) We have had occasional problems with the hardware, but ACC has been quite responsive. I would be glad to discuss this in more depth, if you're interested. Ross Patterson Rutgers University Center for Computer and Information Services PATTERSON@BLUE.RUTGERS.EDU ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050204301900> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Fri 2 May 86 12:12:06-PDT Received: from ubc by csnet-relay.csnet id ae12670; 2 May 86 15:01 EDT Date: Fri, 2 May 86 11:30:19 pdt Received: by ubc.csnet id AA17390; Fri, 2 May 86 11:30:19 pdt From: John Demco To: tcp-ip@sri-nic.ARPA Cc: mrose@nrtc-gremlin.ARPA, CLynn@diamond.bbn.com, Harry Forsdick MMDF-Warning: Parse error in original version of preceding line at CSNET-RELAY.ARPA Message-Id: <2718:demco@ean.ubc.cdn> References: <8605021317.AA00743@DIAMOND.BBN.COM> Subject: X.400 Mail Transport I know this isn't TCP related, but I should clarify a bit... The EAN X.400 message system was developed here at the University of British Columbia, and development is continuing. Sydney Development has the commercial rights to EAN. To get back closer to the topic of TCP... EAN implements class 0 of the ISO transport protocol. Above is the X.225 session layer. Below are interfaces to TCP, X.25, DECNET, and TTXP (a protocol based on MMDF for use on asynchronous lines and ITI connections). I am interested in the approach proposed by RFC983 too, although I haven't read the document closely yet. John Demco UBC ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050205173300> Received: from DIAMOND.BBN.COM (SILICA.BBN.COM) by SRI-NIC.ARPA with TCP; Fri 2 May 86 06:42:18-PDT Received: by DIAMOND.BBN.COM (1.1/4.7) id AA00743; Fri, 2 May 86 09:17:33 EDT Date: Fri, 2 May 86 09:17:33 EDT From: Harry Forsdick Message-Id: <8605021317.AA00743@DIAMOND.BBN.COM> To: mrose@nrtc-gremlin.ARPA Subject: Diamond X.400 Mail Transport Cc: CLynn@DIAMOND.BBN.COM, tcp-ip@sri-nic Hi. I was forwarded your message in tcp-ip about X.400. Yes, we have developed an X.400 based mail transport agent for use by the Diamond Multimedia Communications System. You should contact Charlie Lynn (CLynn@BBN) for details. I'm already aware of the Sydney Development Corp's X.400 on top of IP/TCP. I'm not familiar with "ISTC". Who are they and what are they offering in the way of X.400 mail systems? Regards, Harry P.S., Please reply directly since I am not on the tcp-ip list. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050501451700> Received: from LOCUS.UCLA.EDU by SRI-NIC.ARPA with TCP; Mon 5 May 86 09:30:23-PDT From: Jonathan Biggar Received: by RDCF.SDC.UUCP (sdcrdcf) (4.12/0.2.4) id AA19409; Mon, 5 May 86 08:45:17 pdt Date: Mon, 5 May 86 08:45:17 pdt Message-Id: <8605051545.AA19409@RDCF.SDC.UUCP> To: ucla-cs!tcp-ip@sri-nic.arpa Newsgroups: net.unix-wizards,net.lan,mod.protocols.tcp-ip Subject: Problem with IP fragmentation under Sun 3.0 UNIX Expires: References: Sender: Reply-To: jonab@sdcrdcf.UUCP (Jonathan Biggar) Followup-To: Distribution: Organization: System Development Corporation R&D, Santa Monica Keywords: We have a problem with IP fragmentation-reassembly causing bad tcp checksums at the receiving end under Sun 3.0 UNIX. Any pointers to bug fixes related to this for SUN 3.0, SUN 2.0, or 4.2bsd would be appreciated. Jonathan Biggar sdcrdcf!jonab ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050503373400> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Sun 4 May 86 21:43:30-PDT Date: 05-May-86 03:37:34-UT From: mills@dcn6.arpa Subject: Spurious TCP retransmissions from NIC To: tcp-ip@sri-nic.arpa Folks, I have noticed an alarmingly high incidence of TCP retransmissions from NIC on FTP transfers over medium-delay, low-loss paths. On a typical transfer from its ARPANET address via an ARPANET gateway and 4800-bps line for instance, an average of 2.5 packet transissions occured for every packet stored. During this transfer no packets were recorded as lost in either the gateway or destination host - all spurious packets were duplicates. In transfers to an Ethernet host connected via the same path an average of 2.0 packet transmissions occured for every packet stored. I supsect something is wrong in the retransmission-timeout algorithm of the NIC TCP client, since other TOPS-20 hosts do not exhibit anything like this behavior; however, other TOPS-20s seem on the hairy edge of eagerness, since ISI hosts,'f for instance, seem to generate rather more duplicates that, say, Unix hosts over the same paths. Fuzzball hosts (ahem) generate next to none over most paths. It implementors read RFC-889. It would be useful to learn if others can confirm or refute these observations, since NIC is fast becoming a major fountain of data. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050506082500> Received: from ee00.NSWC-NET.ARPA (NSWC-OAS.ARPA) by SRI-NIC.ARPA with TCP; Mon 5 May 86 07:08:06-PDT Date: Mon, 5 May 86 10:08:25 edt From: rhott@NSWC-OAS.ARPA To: tcp-ip@sri-nic.ARPA Subject: Looking for MacIP Has anyone heard of a Macintosh TCP/IP software product called MacIP? I believe it originated at Carnegie Mellon University. Any pointers to users, distributors would be appreciated. Send responses to: rhott@nswc-g.arpa Thanks, bob hott Naval Surface Weapons Center, Dahlgren, VA 22448 Code K33 (Systems Integration and Networking) Milnet mail : rhott@nswc-g.arpa (703) 663 - 7745 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050607161700> Received: from aplvax.ARPA by SRI-NIC.ARPA with TCP; Tue 6 May 86 08:16:16-PDT Received: by aplvax.ARPA (4.12/4.7) id AA06647; Tue, 6 May 86 11:16:17 edt Date: Tue, 6 May 86 11:16:17 edt From: steve@aplvax (Steven Kahn) Message-Id: <8605061516.AA06647@aplvax.ARPA> To: tcp-ip@sri-nic Subject: 1822/X.25 interoperability question First, a naive question about 1822/X.25 interoperability. Is it a reality? We understand that all future PSN hook-ups require X.25. Does this mean that we could establish TCP connections via such an interface to another host that is connected to its PSN via 1822? Now for a totally unrelated question regarding IBM TCP/IP. Do any of the software products for IBM (such as the UCLA code) contain the application level functionality (such as SMTP, Telnet and FTP) that I am used to in the UNIX world? For example, is SMTP integrated into IBM's "mailer"? (You can tell I'm not from the IBM world...) Steve Kahn Johns Hopkins Applied Physics Lab Laurel, MD steve@aplvax.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050608491000> Received: from ipto.ARPA by SRI-NIC.ARPA with TCP; Tue 6 May 86 09:49:23-PDT Received: by ipto.ARPA (4.12/4.7) id AA01962; Tue, 6 May 86 12:49:17 edt Date: Tue 6 May 86 12:49:10-EDT From: Dennis G. Perry Subject: Re: 1822/X.25 interoperability question To: steve@APLVAX.ARPA Cc: tcp-ip@SRI-NIC.ARPA, perry@IPTO.ARPA Message-Id: In-Reply-To: Message from "steve@aplvax (Steven Kahn)" of Tue, 6 May 86 11:16:17 edt Steve, my understanding is that with psn release 5, X.25 and 1822 should be able to talk to each other. Release 5 is almost ready, but required that all C30s be upgraded to C30Es. I believe that this release will occur soon. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050609213500> Received: from ccs.bbn.com by SRI-NIC.ARPA with TCP; Tue 6 May 86 10:33:59-PDT Date: Tue, 6 May 86 13:21:35 EDT From: Robert Myhill Subject: Re: 1822/X.25 interoperability question In-Reply-To: Your message of Tue 6 May 86 12:49:10-EDT To: Dennis G. Perry Cc: steve@aplvax.arpa, tcp-ip@sri-nic.arpa, laube@bbncc2.arpa, seisner@bbnccs.arpa, myhill@bbnccs.arpa, malis@bbnccs.arpa Here are some facts on X.25/1822 interoperability: o In order for an X.25 host and an 1822 host to communicate, the PSN connected to the X.25 host must be running PSN Release 6.0 (note that the PSN at the 1822 end of the connection, or any PSN in between, need not be running PSN Release 6.0). o In order for a PSN to be running Release 6.0, it must be running on a C/30E. o PSN Release 6.0 has been officially released. o The hosts at both ends of an X.25 to 1822 connection must be running TCP/IP on top. I've heard that there are at least a couple of MILNET PSNs running Release 6.0, though I don't know this for a fact. I hope this helps. --Robert ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050621090000> Mail-From: STJOHNS created at 7-May-86 04:09:53 Date: 7 May 1986 04:09-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: 1822/X.25 interoperability question From: STJOHNS@SRI-NIC.ARPA To: myhill@BBNCCS.ARPA Cc: PERRY@IPTO.ARPA, steve@APLVAX.ARPA Cc: tcp-ip@SRI-NIC.ARPA, laube@BBNCC2.ARPA Cc: seisner@BBNCCS.ARPA, malis@BBNCCS.ARPA Message-ID: <[SRI-NIC.ARPA] 7-May-86 04:09:01.STJOHNS> In-Reply-To: The message of Tue, 6 May 86 13:21:35 EDT from Robert Myhill PSN 6.0 is in LIMITED release on the MILNET and is being fielded to meet specific operational needs. As of the last time I looked, there are no nodes on the ARPANET which have PSN 6.0 installed. We have been waiting for the upgrade to C30Es on the ARPANET to be completed (which may have happened even as I type). Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050705060000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Wed 7 May 86 06:12:24-PDT Date: 7 May 1986 09:06:00 EDT Subject: Re: 1822/X.25 interoperability question From: Glen Foster To: STJOHNS@SRI-NIC.ARPA cc: myhill@BBNCCS.ARPA, PERRY@IPTO.ARPA, steve@APLVAX.ARPA, tcp-ip@SRI-NIC.ARPA, laube@BBNCC2.ARPA, seisner@BBNCCS.ARPA, malis@BBNCCS.ARPA In-Reply-To: <[SRI-NIC.ARPA] 7-May-86 04:09:01.STJOHNS> I think that the c/30 -> c/30e upgrade has been completed. The PSN ver. 5.0 software is currently being installed in all Arpanet IMPS (oops, PSNS). PSN 28 was just upgraded yesterday. and I don't think it was one of the first. Our Milnet PSN, on the other hand, was upgraded last September. Glen ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050713044200> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Wed 7 May 86 14:04:36-PDT Received: by cu-arpa.cs.cornell.edu (5.31/4.30) id AA00447; Wed, 7 May 86 17:05:02 EDT Date: Wed, 7 May 86 17:04:42 EDT From: swb@devvax.tn.cornell.edu (Scott Brim) Message-Id: <8605072104.AA03239@devvax.tn.cornell.edu> Received: by devvax.tn.cornell.edu (4.53/4.30) id AA03239; Wed, 7 May 86 17:04:42 EDT To: tcp-ip@sri-nic.arpa Subject: Cisco I have an introductory blurb from Cisco, a company marketing an IP gateway developed at Stanford. Does anyone have a phone number for the company? Any detailed information on how the product behaves, what its advantages and shortcomings are, what interfaces it supports, etc.? Thanks very much, Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050805325400> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Thu 8 May 86 12:37:07-PDT Date: 8 May 1986 12:32:54 PDT From: BRADEN@USC-ISIB.ARPA Subject: Re: 1822/X.25 interoperability question To: steve@APLVAX.ARPA, tcp-ip@SRI-NIC.ARPA cc: BRADEN@USC-ISIB.ARPA In response to the message sent Tue, 6 May 86 11:16:17 edt from steve@aplvax Steve, The "UCLA code" for TCP/IP supports Telnet, FTP, and SMTP under OS/MVS. It interfaces not to the IBM "mailer" (because, incredible as it may seem from our perspective, there is no such critter), but to a mailer written at UCLA for both Bitnet and the Internet. There is a fullscreen 3278 interface to this mailer that is comparable in quality and ease with the mailtool on my Sun workstation, for example. Bob Braden ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050807484500> Received: from trantor.UMD.EDU by SRI-NIC.ARPA with TCP; Thu 8 May 86 08:48:35-PDT Received: by trantor.UMD.EDU (5.5d/umd.04) id AA12113; Thu, 8 May 86 11:48:45 EDT Date: Thu, 8 May 86 11:48:45 EDT From: Louis A. Mamakos Message-Id: <8605081548.AA12113@trantor.UMD.EDU> To: tcp-ip@sri-nic.arpa Subject: ULTRIX 1.2 brokeness They did it again. After all of the flaming about the proper thing for a user telnet program to send for an end-of-line sequence, the ULTRIX 1.2 release is STILL broken. It seems that too many vendors assume that the correct thing is what UNIX does. These protocols are not defined by their actions, but by the specifications in the RFCs. The Wollongong people have this same problem, and are even more unresponsive to the user's needs then most vendors are. It's only a 3 line fix to make TELNET work. Oh well. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050809140000> Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Thu 8 May 86 16:35:49-PDT Date: 8 May 1986 16:14-PDT Sender: BILLW@SU-SCORE.ARPA Subject: Re: Cisco From: William "Chops" Westfield To: swb@DEVVAX.TN.CORNELL.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SU-SCORE.ARPA] 8-May-86 16:14:34.BILLW> In-Reply-To: <8605072104.AA03239@devvax.tn.cornell.edu> cisco Systems, Inc PO Box 475 Menlo Park, CA, 94026 (415) 326-1941 5106016967 (telex) They sell the IP gateway, a terminal server (talks TCP), and the MEIS, a massbus ethernet interface (eg for 20's). The gateway supports "Sun" 3Mb ethernet interfaces, 3com 10Mb interfaces, Interlan/micom 10Mb interfaces, ACC 1822 interfaces, and 56Kbps serial links, and others (up to 4 at once). The box is multibus based, so other interface support is feasible. Full support of IP, TCP, ICMP, EGP, ARP, Subnets, etc, and "IGP" (Internal Gateway Protocol (supports multipath routing, etc)). Stanford has about 25 of the "non-production" version linking together their 60 odd cable segments, along with about 60 of the "terminal servers". It all works quite well. Disclaimer: I dont for for cisco, but my boss does. I DO work for Stanford. BillW ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050809365400> Received: from merlin.Purdue.EDU by SRI-NIC.ARPA with TCP; Thu 8 May 86 12:38:00-PDT Message-Id: <8605081936.AA01772@merlin.Purdue.EDU> Received: by merlin.Purdue.EDU; Thu, 8 May 86 14:36:59 EST To: "Louis A. Mamakos" Cc: tcp-ip@sri-nic.arpa Subject: Re: ULTRIX 1.2 brokeness In-Reply-To: Your message of Thu, 8 May 86 11:48:45 EDT. <8605081548.AA12113@trantor.UMD.EDU> Date: 08 May 86 14:36:54 EST (Thu) From: "Christopher A. Kent" Well, the story I get from the folks that actually put Ultrix together is that it takes 10 - 12 months to get changes out the door. So Ultrix 1.2 was probably frozen long before our flaming. Sigh, chris ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050810432700> Received: from mitre-bedford.ARPA by SRI-NIC.ARPA with TCP; Thu 8 May 86 16:03:55-PDT Full-Name: Stanley R. Ames Message-Id: <8605082303.AA12216@mitre-bedford.ARPA> Organization: The MITRE Corp., Bedford, MA To: tcp-ip@sri-nic.ARPA, info-ibmpc@usc-isib.ARPA Cc: sra@mitre-bedford.ARPA Subject: Net Bios on top of TCP/IP Date: Thu, 08 May 86 19:03:27 -0500 From: Stan Ames Recently several vendors (including Excelan, UB, and CMC) have anounced products that support the IBM/Microsoft Net Bios on top of the TCP/IP/UDP internet protocols for IEEE 802.3 LAN products. Unfortuantly each has interfaced Net Bios to the internet protocols in a somewhat different mannor. MITRE under the direction of the ULANA program office is attempting to bring the vendors together to agree on an interface specification. In order to be successful each of the vendors must participate and users must make their desires for vendor interoperability known to the vendors. Anyone that is involved in an inpending implementation of Net Bios on the internet protocols is encouraged to participate. Stan Ames sra@mitre-bedford.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050816130000> Received: from BUCS20.BU.EDU by SRI-NIC.ARPA with TCP; Thu 8 May 86 17:15:49-PDT Date: Thu, 8 May 1986 20:13 EDT Message-ID: <[BUCS20.BU.EDU].JSOL. 8-May-86 20:13:35> From: Jon Solomon To: tcp-ip@sri-nic.arpa Subject: 4.2/4.3 subnetting Phase-Of-The-Moon: NM+11H.30M.18S. I have received numerous replies to my subnetting queries and here is a summary of the results. 1) Subnets aren't anywhere near fully implemented in the field. With the growing number of networks out there and the finite amount of network space it makes sense to utilize all the resources as well as one can. 2) 4.2 has no subnetting support. 4.3 apparently does have full subnetting support. 3) If you have ARP based networks then you can use a hack to implement subnets. This is known as "the ARP hack". I now have a copy of this hack for 4.3, but are in need of it for 4.2. Does anyone have a copy of it they'd be willing to give me? Oh, incidentally the 4.3 ARP hack implementation can be gotten from sally.utexas.edu using the anonymous FTP convention, if memory serves. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050820155600> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Thu 8 May 86 21:19:34-PDT Date: Fri, 9 May 86 0:15:56 EDT From: Ron Natalie To: Jon Solomon cc: tcp-ip@sri-nic.arpa Subject: Re: 4.2/4.3 subnetting By the way, if you plan to talk to 4.2 machines using the ARP hack (i.e. you are going to treat the 4.2 machines as being ignorant about subnets), you must fix the code that references the "oldmap" variable as this will prevent ARP from working on the entire 16 bit address. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050820303100> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Thu 8 May 86 21:34:25-PDT Date: Fri 9 May 86 00:30:31-EDT From: "J. Noel Chiappa" Subject: Re: Cisco To: BillW@SU-SCORE.ARPA, swb@devvax.tn.cornell.edu cc: tcp-ip@SRI-NIC.ARPA, JNC@XX.LCS.MIT.EDU In-Reply-To: <[SU-SCORE.ARPA] 8-May-86 16:14:34.BILLW> Message-ID: <12205211742.10.JNC@XX.LCS.MIT.EDU> Are there working examples of the EGP and ARPANet interface, or is that merely an announced product? Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050904210700> Received: from mouton.bellcore.com by SRI-NIC.ARPA with TCP; Fri 9 May 86 05:21:33-PDT Received: from sabre.bellcore.com by mouton.bellcore.com (4.12/4.7) id AA24554; Fri, 9 May 86 08:22:07 edt Received: from blade.bellcore.com (blade.ARPA) by sabre.bellcore.com (4.12/SMI-2.0mjl) id AA19586; Fri, 9 May 86 08:20:32 edt Received: by blade.bellcore.com (4.12/SMI-2.0mjl) id AA04548; Fri, 9 May 86 08:21:07 edt Date: Fri, 9 May 86 08:21:07 edt From: martin%sabre@mouton.bellcore.com (Martin J Levy) Message-Id: <8605091221.AA04548@blade.bellcore.com> To: tcp-ip@sri-nic.arpa Subject: Re: ULTRIX 1.2 brokeness can i also bring up the subject of UDP broadcast's (this is with ULTRIX-32m). i'm coming to the conclusion that there is a mix of 4.2 and 4.3 style code in there for allowing a user to do a broadcast. in 4.2 one only needs to be root to send a broadcast, but with ULTRIX 1.1 it seems you need so do the setsockopt() also, but the correct defines are not in socket.h. can anyone help?, is 1.2 fixed? martin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050905140000> Received: from MIT-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Fri 9 May 86 13:34:28-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2693507139631813@MIT-MULTICS.ARPA>; 09 May 1986 16:25:39 edt Date: 09 May 86 01:54 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: Specs for TCP/IP on Ethernet for t20 Message-ID: <172231@QZCOM> Maybe sending to a black hole.... I'm trying to find the specs, that describes what goes on the ethernet cable, from a TCP/IP taking T20 6.1 arpa monitor. (.trying to hook a t10 7.02 with homebuild ethernet hardware into such network.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050906050000> Received: from BUCS20.BU.EDU by SRI-NIC.ARPA with TCP; Fri 9 May 86 07:07:29-PDT Date: Fri, 9 May 1986 10:05 EDT Message-ID: <[BUCS20.BU.EDU].JSOL. 9-May-86 10:05:00> From: Jon Solomon To: Ron Natalie Cc: tcp-ip@sri-nic.arpa Subject: 4.2/4.3 subnetting Phase-Of-The-Moon: NM+1D.1H.25M.19S. In-reply-to: Msg of 9 May 1986 00:15-EDT from Ron Natalie Date: Friday, 9 May 1986 00:15-EDT From: Ron Natalie To: Jon Solomon cc: tcp-ip at sri-nic.arpa Re: 4.2/4.3 subnetting By the way, if you plan to talk to 4.2 machines using the ARP hack (i.e. you are going to treat the 4.2 machines as being ignorant about subnets), you must fix the code that references the "oldmap" variable as this will prevent ARP from working on the entire 16 bit address. -Ron Explain more.....Do you have such a fix? --jsol ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986050918081200> Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Fri 9 May 86 19:08:51-PDT Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Fri, 9 May 86 22:08:12 edt Date: Fri, 9 May 86 22:08:12 edt From: jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen) Message-Id: <8605100208.AA03765@BORAX.LCS.MIT.EDU> To: tcp-ip@sri-nic.arpa Subject: Ultrix 1.2 One of our customers has reported that TFTP clients which can talk to Ultrix 1.1 just fine can't communicate with Ultrix 1.2. Anyone else experienced this? jbvb@AI.AI.MIT.EDU James B. VanBokkelen ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051004473200> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Fri 9 May 86 21:48:22-PDT Date: 10-May-86 04:47:32-UT From: mills@dcn6.arpa Subject: TCP retransmissions from NIC To: tcp-ip@sri-nic.arpa Folks, Thanks to Alan Hill of BBN and Bob Knight and Mark Lottor at NIC for their comments on my message about excessive TCP retransmissions. Measurements made tonight (about 0400Z) show some improvement. Via the NIC MILNET address, ARPANET/MILNET gateway complex, DCN-GATEWAY and 4800-bps line to DCN6.ARPA, about one packet in 23 was dropped and one packet in seven was an old duplicate. Via the NIC ARPANET address and the same path, about one packet in 212 was dropped and one packet in 14 was an old duplicate. These figures represent a significant improvement over the figures I reported last week, but still leave room for improvement. I have not measured the performance via higher-speed paths, but suspect it is much better than before. I would like to thank the folk both at NIC and BBN for their quick response and prompt action on my message. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605102046.AA26997%40ucbvax.Berkeley.EDU] <1986051012473300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mills@DCN6.ARPA Newsgroups: mod.protocols.tcp-ip Subject: TCP retransmissions from NIC Message-ID: <8605102046.AA26997@ucbvax.Berkeley.EDU> Date: Sat, 10-May-86 16:47:33 EDT Article-I.D.: ucbvax.8605102046.AA26997 Posted: Sat May 10 16:47:33 1986 Date-Received: Mon, 12-May-86 21:01:53 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Folks, Thanks to Alan Hill of BBN and Bob Knight and Mark Lottor at NIC for their comments on my message about excessive TCP retransmissions. Measurements made tonight (about 0400Z) show some improvement. Via the NIC MILNET address, ARPANET/MILNET gateway complex, DCN-GATEWAY and 4800-bps line to DCN6.ARPA, about one packet in 23 was dropped and one packet in seven was an old duplicate. Via the NIC ARPANET address and the same path, about one packet in 212 was dropped and one packet in 14 was an old duplicate. These figures represent a significant improvement over the figures I reported last week, but still leave room for improvement. I have not measured the performance via higher-speed paths, but suspect it is much better than before. I would like to thank the folk both at NIC and BBN for their quick response and prompt action on my message. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605110524.AA06437%40gaston.SPAR.CAS.SLB.COM] <1986051021242700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: faunt@spar.UUCP (Doug Faunt) Newsgroups: mod.protocols.tcp-ip Subject: info on cisco Message-ID: <8605110524.AA06437@gaston.SPAR.CAS.SLB.COM> Date: Sun, 11-May-86 01:24:27 EDT Article-I.D.: gaston.8605110524.AA06437 Posted: Sun May 11 01:24:27 1986 Date-Received: Mon, 12-May-86 21:37:18 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Phone number is 415-326-1941. IP gateway is 1-4 way, currently supports IP/TCP and V.35. Coming soon is T1 and DECNET-IP. Price is $7950 for 2-way IP. Add or subtract $1K for less/more ethernets. Each 2-line v.35 (for muxing high-speed (usually 56Kb) phone lines onto ethernet) interface is $2K. Advantages: has run onder 24 different implementations of IP/TCP and has all boot loaders, servers, and net mgmt. stuff in ROM in the box, so you don't need any other box to do diagnostics or traffic management. Also, the command lang. interface is very good, and nearly everything is user-settable in the config. files. Two levels of password protection on idividual lines to net segments. Fast: 1200 pps burst. For more information, contact cisco or BOSACK@SU-SCORE.ARPA I don't work for cisco, but my boss does. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860513093608.7.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986051305360000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SCRC-YUKON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Port Collisions Message-ID: <860513093608.7.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Tue, 13-May-86 09:36:00 EDT Article-I.D.: REDWING.860513093608.7.MARGULIES Posted: Tue May 13 09:36:00 1986 Date-Received: Wed, 14-May-86 17:45:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa Folks, This mail is a follow-up to a discussion I had with Jon some weeks ago. We here at Symbolics are concerned with the process of assigning TCP/UDP port numbers. It is not always appropriate for us (and other vendors) to apply for ports in the Czar-controlled first 256 ports. Either because of time constraints or issues of proprietary information, we cannot always write and distribute an RFC for each of our protocols. We have had complaints from customers that we are not the only vendor using the `any private file proctocol' port. We need a way to define new protocols without feat of collision with other people. We see two possibilities: 1) A registry of ports for private protocols. Symbolics would be willing to administer a simple registry for a group of ports outside the first 256. We (or someone else, it matters not) would keep a list, and anyone from an identifiable organization could ask for ports. The registrar's only function would be to hand out each such port only once. It would be helpful, of course, if the official RFC's for TCP/UDP would designate the group of ports involved as reserved for use through this registry. 2) A new protocol that would vastly increase the effective namespace by multiplexing ports. For example, a port that the user side connects to and sends an arbitrary (or at least a reasonably long) character string specifying the service desired. Some obvious use of prefixes or suffices would suffice to avoid collisions. --benson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051311380000> Mail-From: STJOHNS created at 13-May-86 18:39:43 Date: 13 May 1986 18:38-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Port Collisions From: STJOHNS@SRI-NIC.ARPA To: Margulies@SCRC-YUKON.ARPA Cc: tcp-ip@SRI-NIC.ARPA Cc: postel%usc-isib.arpa@MC.LCS.MIT.EDU Message-ID: <[SRI-NIC.ARPA]13-May-86 18:38:48.STJOHNS> In-Reply-To: <860513093608.7.MARGULIES@REDWING.SCRC.Symbolics.COM> I am not sure I see the problem here. A "private file protocol" is just that - PRIVATE. It is run between machines that make the assumption that they are all running the same private protocol. Or is there the possibility that one machine is running multiple PRIVATE file protocols? Either a protocol is a network wide standard - implying that is is documented, and that it is designed for at least a minimum of interoperability - or it is private, with little or no public documentation, and with no designed interoperability. In this context, I am talking about global interoperability, not just interoperability between UNIX systems for example. I can see some advantage though in providing some sort of sentinal as part of the PRIVATE protocols to say "I am running FOO as my private protocol, go away if you don't talk FOO". But wouldn't this more properly be part of the protocol? Each protocol should do some confirmation for robustness purposes, right? Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605141645.AA16999%40ucbvax.Berkeley.EDU] <1986051313254600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tef@virginia.CSNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP-IP Mailing List Message-ID: <8605141645.AA16999@ucbvax.Berkeley.EDU> Date: Tue, 13-May-86 17:25:46 EDT Article-I.D.: ucbvax.8605141645.AA16999 Posted: Tue May 13 17:25:46 1986 Date-Received: Thu, 15-May-86 23:47:40 EDT Sender: usenet@ucbvax.BERKELEY.EDU Organization: U.Va. CS dept. Charlottesville, VA Lines: 18 Approved: tcp-ip@sri-nic.arpa Please add me to the tcp-ip mailing list. Thanks, Todd Fuller tef@uvacs.UUCP *************************************************************************** Todd E. Fuller University of Virginia Dept. of Computer Science Path: ...cbosgd!uvacs!tef ...whuxlm!uvacs!tef ...mcnc!ncsu!uvacs!tef ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051313254601> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Tue 13 May 86 20:15:22-PDT Received: from virginia by csnet-relay.csnet id ac13854; 13 May 86 22:59 EDT Received: by uvacs.UUCP (4.12/5.1.UVA) id AA14770; Tue, 13 May 86 17:25:46 edt Date: Tue, 13 May 86 17:25:46 edt From: Todd Eugene Fuller Posted-Date: Tue, 13 May 86 17:25:46 edt To: tcp-ip@SRI-NIC.ARPA Subject: TCP-IP Mailing List Organization: U.Va. CS dept. Charlottesville, VA Cc: Please add me to the tcp-ip mailing list. Thanks, Todd Fuller tef@uvacs.UUCP *************************************************************************** Todd E. Fuller University of Virginia Dept. of Computer Science Path: ...cbosgd!uvacs!tef ...whuxlm!uvacs!tef ...mcnc!ncsu!uvacs!tef ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051314424900> Received: from LOKI.BBN.COM by SRI-NIC.ARPA with TCP; Tue 13 May 86 18:32:37-PDT To: margulies@scrc-yukon.arpa cc: tcp-ip@sri-nic.arpa Subject: re: Port Collisions Date: Tue, 13 May 86 21:22:49 -0400 From: Craig Partridge > We here at Symbolics are concerned with the process of assigning TCP/UDP > port numbers. It is not always appropriate for us (and other vendors) > to apply for ports in the Czar-controlled first 256 ports. Either > because of time constraints or issues of proprietary information, we > cannot always write and distribute an RFC for each of our protocols. Why not make the port numbers used user/site configurable? Berkeley actually did this quite nicely with a services list, which mapped a service name/protocol pair with a port number. Since programs use this database (or are supposed to) to find out what port they are supposed to us, one could run SMTP on TCP port 25 on the Internet but port 243 on some private network if one so chose. The advantage is the vendor need not necessarily worry about what port you pick for your special application -- it can always be changed among cooperating machines. Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BSRI-NIC.ARPA%5D13-May-86.18:38:48.STJOHNS] <1986051317380000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: STJOHNS@SRI-NIC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <[SRI-NIC.ARPA]13-May-86.18:38:48.STJOHNS> Date: Tue, 13-May-86 21:38:00 EDT Article-I.D.: <[SRI-NIC.ARPA]13-May-86.18:38:48.STJOHNS> Posted: Tue May 13 21:38:00 1986 Date-Received: Wed, 14-May-86 17:47:15 EDT References: <860513093608.7.MARGULIES@REDWING.SCRC.Symbolics.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa I am not sure I see the problem here. A "private file protocol" is just that - PRIVATE. It is run between machines that make the assumption that they are all running the same private protocol. Or is there the possibility that one machine is running multiple PRIVATE file protocols? Either a protocol is a network wide standard - implying that is is documented, and that it is designed for at least a minimum of interoperability - or it is private, with little or no public documentation, and with no designed interoperability. In this context, I am talking about global interoperability, not just interoperability between UNIX systems for example. I can see some advantage though in providing some sort of sentinal as part of the PRIVATE protocols to say "I am running FOO as my private protocol, go away if you don't talk FOO". But wouldn't this more properly be part of the protocol? Each protocol should do some confirmation for robustness purposes, right? Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D13-May-86.22:13:10.CERF] <1986051318130000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@USC-ISI.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: C implementations of TCP/IP Message-ID: <[USC-ISI.ARPA]13-May-86.22:13:10.CERF> Date: Tue, 13-May-86 22:13:00 EDT Article-I.D.: <[USC-ISI.ARPA]13-May-86.22:13:10.CERF> Posted: Tue May 13 22:13:00 1986 Date-Received: Thu, 15-May-86 23:49:31 EDT Sender: jsc@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Are there any public domain implementations of TCP/IP written in C which are readily accessible? With documentation? Many thanks, Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051318130001> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Tue 13 May 86 19:13:32-PDT Date: 13 May 1986 22:13-EDT Sender: CERF@USC-ISI.ARPA Subject: C implementations of TCP/IP From: CERF@USC-ISI.ARPA To: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]13-May-86 22:13:10.CERF> Are there any public domain implementations of TCP/IP written in C which are readily accessible? With documentation? Many thanks, Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605140213.AA06443%40ucbvax.Berkeley.EDU] <1986051318163900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: craig@LOKI.BBN.COM (Craig Partridge) Newsgroups: mod.protocols.tcp-ip Subject: re: Port Collisions Message-ID: <8605140213.AA06443@ucbvax.Berkeley.EDU> Date: Tue, 13-May-86 22:16:39 EDT Article-I.D.: ucbvax.8605140213.AA06443 Posted: Tue May 13 22:16:39 1986 Date-Received: Wed, 14-May-86 17:46:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa > We here at Symbolics are concerned with the process of assigning TCP/UDP > port numbers. It is not always appropriate for us (and other vendors) > to apply for ports in the Czar-controlled first 256 ports. Either > because of time constraints or issues of proprietary information, we > cannot always write and distribute an RFC for each of our protocols. Why not make the port numbers used user/site configurable? Berkeley actually did this quite nicely with a services list, which mapped a service name/protocol pair with a port number. Since programs use this database (or are supposed to) to find out what port they are supposed to us, one could run SMTP on TCP port 25 on the Internet but port 243 on some private network if one so chose. The advantage is the vendor need not necessarily worry about what port you pick for your special application -- it can always be changed among cooperating machines. Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860514-023737-4874%40Xerox] <1986051401372500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Murray.pa@XEROX.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860514-023737-4874@Xerox> Date: Wed, 14-May-86 05:37:25 EDT Article-I.D.: Xerox.860514-023737-4874 Posted: Wed May 14 05:37:25 1986 Date-Received: Thu, 15-May-86 23:47:59 EDT References: <860513093608.7.MARGULIES@REDWING.SCRC.Symbolics.COM> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa One word of caution.... Xerox managed to get off on the wrong foot in the Ethernet packet type assignment business. If you administer a group of ports, I suggest that the ground rules include publishing a who-to-contact as well as a simple (one line?) description of its function. Otherwise people will flame at you when you won't answer questions. The proprietary aspect might complicate that attitude. I don't think that objection really holds water. It's too easy to look at the bits on an ethernet. I like your second suggestion, but somebody is bound to ignore it because it takes an extra packet to get started. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860514074552.6.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986051403450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SCRC-YUKON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860514074552.6.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Wed, 14-May-86 07:45:00 EDT Article-I.D.: REDWING.860514074552.6.MARGULIES Posted: Wed May 14 07:45:00 1986 Date-Received: Fri, 16-May-86 01:37:10 EDT References: <[SRI-NIC.ARPA]13-May-86.18:38:48.STJOHNS> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 66 Approved: tcp-ip@sri-nic.arpa Date: 13 May 1986 18:38-PDT From: STJOHNS@SRI-NIC.ARPA I am not sure I see the problem here. A "private file protocol" is just that - PRIVATE. It is run between machines that make the assumption that they are all running the same private protocol. Wrong meaning of private. Try the definition `A protocol not published as an RFC, for any reason whatsoever.' Or is there the possibility that one machine is running multiple PRIVATE file protocols? Exactly. Symbolics has a 'private' file protocol. One of our customers wanted to teach their lisp machine to talk someone elses 'private' file protocol. Unfortunately, they were on the same port. This situation is typical, and likely to happen again and again. Either a protocol is a network wide standard - implying that is is documented, and that it is designed for at least a minimum of interoperability - or it is private, with little or no public documentation, and with no designed interoperability. In this context, I am talking about global interoperability, not just interoperability between UNIX systems for example. The problem is with the phrase `network-wide standard'. The number czar only designates protocols as `network-wide standards' as part of the activity of the internet research community (I'm paraphrasing Jon Postel, and I hope that I'm getting it right). That is not to say that vendors cannot offer protcols for inclusion in the global set. However, it is often not practical for us to do so. We can't always afford the time to document the protocol for the community, which is a pretty-near necessart for inclusion in the global protocol set. Anyway, I don't think that your simple division of the world into Public and Private is good enough. I think that things are more complex. First, there is an extensive gray area between officially blessed protocols (global interoperability) and protocols that are private hacks amongst a small number of cooperative machines (no interoperability). As a commercial vendor, we are concerned with orderly partial inter-operability. If Berkley has established a 'private' Unix TCP protocol, it is very likely that sooner or later someone with a lisp machine (or something else non-Unix) will want to talk that protocol to a Unix. That dosen't necessarily qualify the protocol as a network-wide standard, but gives a good reason for us to avoid port collisions. Second, even if I were implementing a protocol that would only be used at one site amongst three machines, I would like some assurance that I won't find out next week that some vendor is using the port that I chose for some protocol that I am interested in using. I can see some advantage though in providing some sort of sentinal as part of the PRIVATE protocols to say "I am running FOO as my private protocol, go away if you don't talk FOO". But wouldn't this more properly be part of the protocol? Each protocol should do some confirmation for robustness purposes, right? Indeed, its not hard to say `sorry, you can't talk to him, because he's doing something else over that port.' Cold comfort if your goal is to talk to him. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860514074922.7.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986051403490000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SCRC-YUKON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860514074922.7.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Wed, 14-May-86 07:49:00 EDT Article-I.D.: REDWING.860514074922.7.MARGULIES Posted: Wed May 14 07:49:00 1986 Date-Received: Wed, 14-May-86 22:49:01 EDT References: <860514-023737-4874@Xerox> Sender: jsc@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Date: Wed, 14 May 86 02:37:25 PDT From: Murray.pa@Xerox.COM One word of caution.... Xerox managed to get off on the wrong foot in the Ethernet packet type assignment business. If you administer a group of ports, I suggest that the ground rules include publishing a who-to-contact as well as a simple (one line?) description of its function. Otherwise people will flame at you when you won't answer questions. Fine with me. The proprietary aspect might complicate that attitude. I don't think that objection really holds water. It's too easy to look at the bits on an ethernet. I expect that proprietary protocols will be fairly rare. Mostly, I expect that people just won't have the time or inclination to document. I really cannot see why someone would insist on a listing of `Foobar Company proprietary protocol 1'. I like your second suggestion, but somebody is bound to ignore it because it takes an extra packet to get started. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860514110721.9.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986051407070000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@SCRC-QUABBIN.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860514110721.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Wed, 14-May-86 11:07:00 EDT Article-I.D.: FIREBIRD.860514110721.9.DCP Posted: Wed May 14 11:07:00 1986 Date-Received: Wed, 14-May-86 22:49:20 EDT References: <860514-023737-4874@Xerox> Sender: jsc@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Date: Wed, 14 May 86 02:37:25 PDT From: Murray.pa@Xerox.COM I like your second suggestion, but somebody is bound to ignore it because it takes an extra packet to get started. For reference, I suggest people read the documentation for the CHAOSNET protocol, MIT A.I. Memo 628. Basically, CHAOSNET wins in the connection initiation methodology and the IP-class of protocols lose. Small fields (read: numbers) that require a number czar make ease of extension very difficult. In chaos it is easy to say "I want to invent a protocol called RESET-TIME-SERVER" because the name of the protocol can also be the contact name used in the RFC (SYN, for TCP folks). I have a feeling TP4 loses in this respect as well. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051408050600> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 14 May 86 15:25:11-PDT Date: 14 May 1986 15:05:06 PDT From: POSTEL@USC-ISIB.ARPA Subject: re: port collisions To: TCP-IP@SRI-NIC.ARPA Hi. The number czar is primarily interested in having the protocols assigned ports from the reserved space (numbers 0 through 255) be documented and public. It does not really matter much if the protocol is developed for academic internet research or practical commercial use. It does matter that there be some good reason for the protocol and that there be some evidience that some work was actually done on the protocol. The number czar dislikes assigning numbers on speculation (that is, tends to turn down requests of the form "I might write some protocols, give me a bunch of port numbers"). There are already a few assignments for essentially private protocols (some that would not be made today), but in most of these recent cases the developer was able to send the czar some description of the protocol. One of the great things about the Internet is that is an "open system", and what that means is that the protocols are public. Over and over the czar has seen people develop some little hack protocol for their own private use that turns out to be a neat thing and other people want to use it too but it is not documented. If there really is a need for a set of port numbers to be assigned to individuals or companies for private use, the number czar is perfectly happy to do the work of keeping track of who owns which numbers and giving the next available number to the next requestor. If this is a thing we want to do what part of the port number space should be allocated to this? How many numbers should be set aside for this type of assignment? What is the impact on existing programs and systems? Is anyone using the numbers that will suddenly be off limits by this this reservation of part of the port number space? Or if the other suggestion is followed (to have a port assigned for a multiplexing service based on a character string argument), the number czar is happy to keep the list of unique (initial) strings and who is the contact person. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12206659223.23.PATTERSON%40BLUE.RUTGERS.EDU] <1986051409014600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PATTERSON@BLUE.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <12206659223.23.PATTERSON@BLUE.RUTGERS.EDU> Date: Wed, 14-May-86 13:01:46 EDT Article-I.D.: BLUE.12206659223.23.PATTERSON Posted: Wed May 14 13:01:46 1986 Date-Received: Fri, 16-May-86 01:41:53 EDT References: <860514110721.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Yes, but then you have collision problems with protocol names. Most people would use acronyms, not word-by-word forms. You still need a Socket Czar, only now sockets have a (reasonably) human-understandable format (i.e TELNET instead of 23.) Ross Patterson Center for Computer and Information Services Rutgers University ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605141747.AA04242%40isi-braden.arpa] <1986051409472700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI-BRADEN.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <8605141747.AA04242@isi-braden.arpa> Date: Wed, 14-May-86 13:47:27 EDT Article-I.D.: isi-brad.8605141747.AA04242 Posted: Wed May 14 13:47:27 1986 Date-Received: Fri, 16-May-86 01:42:49 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa It sounds like another version of the SNA/DECNET free-enterprise protocol wars. Do you think we should encourage the proliferation of private protocols, many of them doing the same things? It is clearly in the national interest (that's us, friends) to promote maximal interconnection of heterogeneous systems. That is what standards are for. Until recently, in England there were several different standards for electric plugs, because each of the 19th century power barons designed their own. So you bought an appliance with a cord but no plug on the end, and added the plug necessary for your outlet. Rather like a configuration file, isn't it? As a customer, do you think I should buy a software system from a vendor that did not have the resources to properly document its internal function? I wonder what kind of maintenance and support I will get with that product. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051409560200> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Wed 14 May 86 12:59:12-PDT Date: 14 May 1986 14:56:02 CDT Subject: [domiller@lognet2.ARPA (Donald G. Miller): HP 3000] From: AFDDN.BEACH@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Anybody know where one of these monsters is? Darrel --------------- Return-Path: Received: FROM LOGNET2.ARPA BY GUNTER-ADAM.ARPA WITH TCP ; 13 May 86 10:15:45 CDT Return-Path: Received: by lognet2.ARPA id AA11563; Tue, 13 May 86 11:15:36 edt Message-Id: <8605131515.AA11563@lognet2.ARPA> Date: Tue May 13 11:15:33 1986 From: domiller@lognet2.ARPA (Donald G. Miller) Subject: HP 3000 To: afddn.beach@gunter-adam Status: N Is there anyone on the DDN with full suite or working a full suite on an HP 3000???? If so can you give me a POC?? tks don m ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860514143607.6.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986051410360000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@SCRC-QUABBIN.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860514143607.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Wed, 14-May-86 14:36:00 EDT Article-I.D.: FIREBIRD.860514143607.6.DCP Posted: Wed May 14 14:36:00 1986 Date-Received: Fri, 16-May-86 02:00:15 EDT References: <12206659223.23.PATTERSON@BLUE.RUTGERS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Date: 14 May 86 13:01:46 EDT From: Ross Patterson Yes, but then you have collision problems with protocol names. Most people would use acronyms, not word-by-word forms. You still need a Socket Czar, only now sockets have a (reasonably) human-understandable format (i.e TELNET instead of 23.) Go read Benson's message again. He said that private protocols would be rather long contact names, possibly including the vendor/entity that implemented it as part of the name. People who use short names or acronyms are anti-social. Standard contact-names that correspond to RFCs could still be administered by a Czar, e.g., TELNET, SUPDUP, ECHO, but private protocols would have names like SYMBOLICS-NFILE. Benson and I have already colided, AND WE'RE ON THE SAME FLOOR OF THE SAME BUILDING OF THE SAME COMPANY. Since numbers don't mean anything, we both happened to pick 666 for our private port number. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051410370000> Received: from TYCHO by SRI-NIC.ARPA with TCP; Wed 14 May 86 11:49:10-PDT Date: 14 May 1986 at 1437-EDT Subject: re: C implementations of TCP/IP From: hsw at TYCHO.ARPA (Howard Weiss) To: cerf at isi cc: tcp-ip at nic Vint, I have a version of TCP/IP that was written by BBN under DCA sponsorship. This version was written in C and runs on V6 UNIX. There is some documentation and it currently runs on the internet at both our site and at DCEC. Also, this is the version that Honeywell converted to run on the SCOMP. Howard Weiss National Computer Security Center (301) 859-4491 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860514144516.8.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986051410450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SCRC-YUKON.ARPA (Benson I. Margulies) Newsgroups: mod.protocols.tcp-ip Subject: re: Port Collisions Message-ID: <860514144516.8.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Wed, 14-May-86 14:45:00 EDT Article-I.D.: REDWING.860514144516.8.MARGULIES Posted: Wed May 14 14:45:00 1986 Date-Received: Thu, 15-May-86 23:48:38 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa Date: Tue, 13 May 86 21:22:49 -0400 From: Craig Partridge > We here at Symbolics are concerned with the process of assigning TCP/UDP > port numbers. It is not always appropriate for us (and other vendors) > to apply for ports in the Czar-controlled first 256 ports. Either > because of time constraints or issues of proprietary information, we > cannot always write and distribute an RFC for each of our protocols. Why not make the port numbers used user/site configurable? Berkeley actually did this quite nicely with a services list, which mapped a service name/protocol pair with a port number. Since programs use this database (or are supposed to) to find out what port they are supposed to us, one could run SMTP on TCP port 25 on the Internet but port 243 on some private network if one so chose. We believe in 'plug-in-and-play' software. Expecting not-very-savy users to figure out the port usage of all the various programs they are using is a big expectation. What if two sites disagree on the port for a protocol? They will never be able to inter-operate! We have logical services and protocols that are mapped to ports. The only way to make that do what you want is to use a different protocol name for each port assignment in use anyplace, so that the database of hosts can indicate which hosts are going to talk over which ports. This is an unreasonable burden. The advantage is the vendor need not necessarily worry about what port you pick for your special application -- it can always be changed among cooperating machines. Its the vendor's job to worry so the user dosen't have to. Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860514145254.9.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986051410520000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SCRC-YUKON.ARPA (Benson I. Margulies) Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860514145254.9.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Wed, 14-May-86 14:52:00 EDT Article-I.D.: REDWING.860514145254.9.MARGULIES Posted: Wed May 14 14:52:00 1986 Date-Received: Thu, 15-May-86 23:55:22 EDT References: <8605141747.AA04242@isi-braden.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa Date: Wed, 14 May 86 10:47:27 PDT From: braden@isi-braden.arpa (Bob Braden) It sounds like another version of the SNA/DECNET free-enterprise protocol wars. Do you think we should encourage the proliferation of private protocols, many of them doing the same things? It is clearly in the national interest (that's us, friends) to promote maximal interconnection of heterogeneous systems. That is what standards are for. Not all protocols are suitable for standardization. Sometimes, there isn't enough knowledge in the industry to settle on a standard. We can't be expected to wait around. Some protocols perform very specific functions that are pointless to standardize. Heavily networked products are very likely to involve network protocols that are not useful outside a particular application. Yet these have to have ports, and those ports can't conflict with other, interoperating protocols. Until recently, in England there were several different standards for electric plugs, because each of the 19th century power barons designed their own. So you bought an appliance with a cord but no plug on the end, and added the plug necessary for your outlet. Rather like a configuration file, isn't it? This is why I'm opposed to the configuration file solution. As a customer, do you think I should buy a software system from a vendor that did not have the resources to properly document its internal function? I wonder what kind of maintenance and support I will get with that product. The statement `did not have the resources' is not a realistic view. As a customer, I'd rather my vendor spent their (my) money on supporting me, not informing the internet community about the network protocols in their product. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12206686220.6.MRC%40PANDA] <1986051411300400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin) Newsgroups: mod.protocols.tcp-ip Subject: private/proprietary protocols Message-ID: <12206686220.6.MRC@PANDA> Date: Wed, 14-May-86 15:30:04 EDT Article-I.D.: PANDA.12206686220.6.MRC Posted: Wed May 14 15:30:04 1986 Date-Received: Fri, 16-May-86 05:16:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Personally, I think that proprietary protocols have no place in the Internet research/military community. They are absolutely not in the best interest of US national defense. Quite enough problems exist because the UUCP protocol is AT&T proprietary. As a software vendor, I sympathize with the need for trade secret and other forms of software protection. However, a deliberate attempt to lock out interoperability with other vendors' products is bad for the customer and ultimately bad for the vendor. Private protocols should be discouraged as much as possible. If a protocol is useful enough to consume part of the Internet namespace, it is useful enough to be documented for the rest of the Internet community. My feeling is that if there MUST be a private protocol assignment it should be "one port per organization", and that organization should make some arrangement to identify which of their private protocols they way (e.g. the first octet from the user agent identifies "MIT protocol #n", or "Symbolics protocol #n", etc.) I have occasionally been frustrated with the delays and paperwork involved in getting numbers assigned by Postel, but at the same time I feel these procedures are necessary. If anything, Jon has erred on the side of giving out a number in questionable circumstances. I vote to keep the current procedure; if it ain't broke don't fix it. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605150221.AA27837%40ucbvax.Berkeley.EDU] <1986051411560200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AFDDN.BEACH@GUNTER-ADAM.ARPA Newsgroups: mod.protocols.tcp-ip Subject: [domiller@lognet2.ARPA (Donald G. Miller): HP 3000] Message-ID: <8605150221.AA27837@ucbvax.Berkeley.EDU> Date: Wed, 14-May-86 15:56:02 EDT Article-I.D.: ucbvax.8605150221.AA27837 Posted: Wed May 14 15:56:02 1986 Date-Received: Fri, 16-May-86 03:46:15 EDT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Anybody know where one of these monsters is? Darrel --------------- Return-Path: Received: FROM LOGNET2.ARPA BY GUNTER-ADAM.ARPA WITH TCP ; 13 May 86 10:15:45 CDT Return-Path: Received: by lognet2.ARPA id AA11563; Tue, 13 May 86 11:15:36 edt Message-Id: <8605131515.AA11563@lognet2.ARPA> Date: Tue May 13 11:15:33 1986 From: domiller@lognet2.ARPA (Donald G. Miller) Subject: HP 3000 To: afddn.beach@gunter-adam Status: N Is there anyone on the DDN with full suite or working a full suite on an HP 3000???? If so can you give me a POC?? tks don m ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605150350.AA29649%40ucbvax.Berkeley.EDU] <1986051414050600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: POSTEL@USC-ISIB.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: port collisions Message-ID: <8605150350.AA29649@ucbvax.Berkeley.EDU> Date: Wed, 14-May-86 18:05:06 EDT Article-I.D.: ucbvax.8605150350.AA29649 Posted: Wed May 14 18:05:06 1986 Date-Received: Fri, 16-May-86 03:52:02 EDT Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 40 Approved: tcp-ip@sri-nic.arpa Hi. The number czar is primarily interested in having the protocols assigned ports from the reserved space (numbers 0 through 255) be documented and public. It does not really matter much if the protocol is developed for academic internet research or practical commercial use. It does matter that there be some good reason for the protocol and that there be some evidience that some work was actually done on the protocol. The number czar dislikes assigning numbers on speculation (that is, tends to turn down requests of the form "I might write some protocols, give me a bunch of port numbers"). There are already a few assignments for essentially private protocols (some that would not be made today), but in most of these recent cases the developer was able to send the czar some description of the protocol. One of the great things about the Internet is that is an "open system", and what that means is that the protocols are public. Over and over the czar has seen people develop some little hack protocol for their own private use that turns out to be a neat thing and other people want to use it too but it is not documented. If there really is a need for a set of port numbers to be assigned to individuals or companies for private use, the number czar is perfectly happy to do the work of keeping track of who owns which numbers and giving the next available number to the next requestor. If this is a thing we want to do what part of the port number space should be allocated to this? How many numbers should be set aside for this type of assignment? What is the impact on existing programs and systems? Is anyone using the numbers that will suddenly be off limits by this this reservation of part of the port number space? Or if the other suggestion is followed (to have a port assigned for a multiplexing service based on a character string argument), the number czar is happy to keep the list of unique (initial) strings and who is the contact person. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SRA.12206717761.BABYL%40XX.LCS.MIT.EDU] <1986051414230000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SRA@XX.LCS.MIT.EDU (Rob Austein) Newsgroups: mod.protocols.tcp-ip Subject: Port Collisions Message-ID: Date: Wed, 14-May-86 18:23:00 EDT Article-I.D.: XX.SRA.12206717761.BABYL Posted: Wed May 14 18:23:00 1986 Date-Received: Fri, 16-May-86 03:51:26 EDT References: Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa The collision problem with protocol names is not as severe as the with (small) protocol numbers. People implementing private applications tend to use ports in the low 500s (or working down from 1024), so there is a fair chance that there will eventually be conflicts. Whereas I doubt that Symbolics would have much trouble testing a new service named "SYMBOLICS-PRIVATE-PROTOCOL-XYZ-PRIME". When a protocol becomes well enough known and widely enough used that it needs a short snappy name, -then- you go talk to the Socket Czar. --Rob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605142343.AA09396%40monet.Berkeley.EDU] <1986051415430200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels@MONET.BERKELEY.EDU (Mike Karels) Newsgroups: mod.protocols.tcp-ip Subject: Re: C implementations of TCP/IP Message-ID: <8605142343.AA09396@monet.Berkeley.EDU> Date: Wed, 14-May-86 19:43:02 EDT Article-I.D.: monet.8605142343.AA09396 Posted: Wed May 14 19:43:02 1986 Date-Received: Fri, 16-May-86 03:52:55 EDT Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa The Berkeley 4.2/4.3BSD TCP/IP code is written in C. It's not quite public domain (it is copyright by the university), but the only restriction on its use is that the University of California be credited. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12206734278.69.JNC%40XX.LCS.MIT.EDU] <1986051415540300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <12206734278.69.JNC@XX.LCS.MIT.EDU> Date: Wed, 14-May-86 19:54:03 EDT Article-I.D.: XX.12206734278.69.JNC Posted: Wed May 14 19:54:03 1986 Date-Received: Fri, 16-May-86 03:57:38 EDT References: <860514110721.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Right. What happens if you pick a name for your private protocol that happens to be exactly the same as the name someone else picked for their private protocol? You are merely using strings instead of numbers; the same problems can happen. The set of possible identifiers is still pretty small, if people use descriptive english words for services. Now, if you preface all your private services with some personal string, e.g. 'SYMBOLICS-', as in 'SYMBOLICS-NEW-FILE' then maybe you have a valid point. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605150106.AA26134%40ucbvax.Berkeley.EDU] <1986051417154400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hsw@TYCHO.ARPA (Howard Weiss) Newsgroups: mod.protocols.tcp-ip Subject: re: C implementations of TCP/IP Message-ID: <8605150106.AA26134@ucbvax.Berkeley.EDU> Date: Wed, 14-May-86 21:15:44 EDT Article-I.D.: ucbvax.8605150106.AA26134 Posted: Wed May 14 21:15:44 1986 Date-Received: Thu, 15-May-86 23:48:55 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa Vint, I have a version of TCP/IP that was written by BBN under DCA sponsorship. This version was written in C and runs on V6 UNIX. There is some documentation and it currently runs on the internet at both our site and at DCEC. Also, this is the version that Honeywell converted to run on the SCOMP. Howard Weiss National Computer Security Center (301) 859-4491 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860514220958.2.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986051418090000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@SCRC-QUABBIN.ARPA (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860514220958.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Wed, 14-May-86 22:09:00 EDT Article-I.D.: FIREBIRD.860514220958.2.DCP Posted: Wed May 14 22:09:00 1986 Date-Received: Fri, 16-May-86 03:59:28 EDT References: <8605141747.AA04242@isi-braden.arpa> Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 46 Approved: tcp-ip@sri-nic.arpa Date: Wed, 14 May 86 10:47:27 PDT From: braden@isi-braden.arpa (Bob Braden) It sounds like another version of the SNA/DECNET free-enterprise protocol wars. Do you think we should encourage the proliferation of private protocols, many of them doing the same things? It is clearly in the national interest (that's us, friends) to promote maximal interconnection of heterogeneous systems. That is what standards are for. Until recently, in England there were several different standards for electric plugs, because each of the 19th century power barons designed their own. So you bought an appliance with a cord but no plug on the end, and added the plug necessary for your outlet. Rather like a configuration file, isn't it? As a customer, do you think I should buy a software system from a vendor that did not have the resources to properly document its internal function? I wonder what kind of maintenance and support I will get with that product. Example. Symbolics calls its current "private file protocol" NFILE. It is currently documented in the Release 6.1 Release Notes. We know it to be far superior to TCP/FTP and pervious file protocols on Lisp Machines. NFILE is a true file ACCESS protocol as oposed to FTP which is a transfer protocol. Back then we weren't ready to tout it to the rest of the world. I'm still not sure we are. The reasons are many. We aren't sure it is really sufficient. We do know that there are some very complex operations in it because of the need to handle aborting out of operations correctly. The generic-file-system model it assumes may not fit in well with all known system. We also fear that many people will not understand the need for some of the complexity and will either want it thrown out because they can't figure out how to implement it, or won't implement the parts without telling people. (Need I remind people that Unix TCP/FTP still sends the wrong code for the DELETE operation, I believe it is.) Companies may be willing to document their protocols to let others experiment with them. They may not be prepared to solidify on it or to change it to the whims of the masses. If NFILE replaced TCP/FTP as the Internet standard, and if we discovered some other feature that is rather crucial to our system, we would be in the same ballpark as we are now: a private protocol. There are sometimes some good reasons not to push private protocols as standards until all the conditions are right, even though those private protocols are documented and provide superior functionality. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BBUCS20.BU.EDU%5D.JSOL.14-May-86.22:28:30] <1986051418280000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSOL@BUCS20.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Documenting locally defined protocols Message-ID: <[BUCS20.BU.EDU].JSOL.14-May-86.22:28:30> Date: Wed, 14-May-86 22:28:00 EDT Article-I.D.: <[BUCS20.BU.EDU].JSOL.14-May-86.22:28:30> Posted: Wed May 14 22:28:00 1986 Date-Received: Fri, 16-May-86 03:48:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa I want to point out that there's a difference between internally (to a company) documenting protocols and reporting those protocols back to the Internet via a RFC. --jsol ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051418280001> Received: from BUCS20.BU.EDU by SRI-NIC.ARPA with TCP; Wed 14 May 86 19:28:52-PDT Date: Wed, 14 May 1986 22:28 EDT Message-ID: <[BUCS20.BU.EDU].JSOL.14-May-86 22:28:30> From: Jon Solomon To: tcp-ip@sri-nic.arpa Subject: Documenting locally defined protocols Phase-Of-The-Moon: NM+6D.13H.47M.54S. I want to point out that there's a difference between internally (to a company) documenting protocols and reporting those protocols back to the Internet via a RFC. --jsol ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12950.516501992%40nrtc-gremlin.northrop.com] <1986051421295700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@NRTC-GREMLIN.ARPA (Marshall Rose) Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <12950.516501992@nrtc-gremlin.northrop.com> Date: Thu, 15-May-86 01:29:57 EDT Article-I.D.: nrtc-gre.12950.516501992 Posted: Thu May 15 01:29:57 1986 Date-Received: Fri, 16-May-86 03:58:55 EDT References: <860514143607.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Sender: daemon@styx.UUCP Reply-To: tcp-ip@sri-nic.arpa Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa If your argument is: "having a port space of 512 distinct addresses is too small" then I doubt anyone dis-agrees in principle. On the other hand, if your argument is: "Benson and I, working on the floor for the same company, collided, so the port space is too small" Then your argument points more to a possible (mis)management problem in your company than a port scarcity problem! Let's face it, 512 distinct addresses for ports probably is too small for the totality of applications that can/could use TCP. I don't think it's too small any given group of co-operating sites using TCP, though I could be convinced otherwise. Personally, I like the Berkeley method since you can just define some numbers to meet your needs. I'm not so keen on using strings or datastructures as port identifiers, though I'm sure, when ISO gets around to defining the port space for TS-users, they'll be sure to add an option for regular expressions, mandelbrots, etc. (-: /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605141340.a000108%40gigue.mcvax.UUCP] <1986051423193700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dpk@mcvax.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <8605141340.a000108@gigue.mcvax.UUCP> Date: Thu, 15-May-86 03:19:37 EDT Article-I.D.: gigue.8605141340.a000108 Posted: Thu May 15 03:19:37 1986 Date-Received: Fri, 16-May-86 04:07:30 EDT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa I like the idea of the "multiplexing port". Consider this one vote for it. -Doug- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860515074902.9.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986051503490000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SCRC-YUKON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860515074902.9.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Thu, 15-May-86 07:49:00 EDT Article-I.D.: REDWING.860515074902.9.MARGULIES Posted: Thu May 15 07:49:00 1986 Date-Received: Fri, 16-May-86 04:37:27 EDT References: <12206734278.69.JNC@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Date: Wed 14 May 86 19:54:03-EDT From: "J. Noel Chiappa" Right. What happens if you pick a name for your private protocol that happens to be exactly the same as the name someone else picked for their private protocol? You are merely using strings instead of numbers; the same problems can happen. The set of possible identifiers is still pretty small, if people use descriptive english words for services. Now, if you preface all your private services with some personal string, e.g. 'SYMBOLICS-', as in 'SYMBOLICS-NEW-FILE' then maybe you have a valid point. That is exactly my plan. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860515080358.4.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986051504030000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SCRC-YUKON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860515080358.4.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Thu, 15-May-86 08:03:00 EDT Article-I.D.: REDWING.860515080358.4.MARGULIES Posted: Thu May 15 08:03:00 1986 Date-Received: Fri, 16-May-86 04:38:02 EDT References: <8605141340.a000108@gigue.mcvax.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa From: Doug Kingston I like the idea of the "multiplexing port". Consider this one vote for it. -Doug- well, so do I. However, for it to be a workable solution, there has to be some commitment that it won't be a member of the large `ignored RFC' collection. I think that we need a registry to tide us over in the interim. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051507220000> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Thu 15 May 86 09:37:54-PDT Received: from (MAILER)HARVARDA.BITNET by WISCVM.WISC.EDU on 05/15/86 at 11:36:39 CDT Received: by HARVARDA (Mailer X1.23b) id 6692; Thu, 15 May 86 12:25:04 EST Date: Thu, 15 May 1986 12:22 EST From: Gary D. Twiraga To: please take my name off your mailing list.... thank gary at harvarda.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051507280000> Received: from LOGICON.ARPA by SRI-NIC.ARPA with TCP; Thu 15 May 86 14:34:04-PDT Date: 15 May 86 14:28 PDT Sender: tom@LOGICON.ARPA From: Jeff Makey , Tom Perrine To: tcp-ip@sri-nic Cc: Tom Perrine , Jeff Makey Subject: Redirect wars and Buterfly gateways This month's issue (May) of "Mini-Micro Systems" has a blurb in the "Breakpoints" section (page 20) about a system called "Monarch", from BBN Laboratories which will have 8,192 parallel processors of an undisclosed type. In the paragraph they mention that, for those who can't wait for Monarch, BBN is shipping something called the "Butterfly" system consisting of 256 Motorola MC68020 processors working in parallel. Is this any relation to the much-alluded-to "Butterfly gateway" which is supposed to save us from the ravages of brain-dead gateways? Speaking of brain-dead gateways, we have had some more instances of the ICMP "redirect wars". This morning SRI-MILNET-GW redirected us to BBN-MILNET-GW, who redirected us back to SRI-MILNET-GW. This happened 11 times in 29 seconds while trying to establish a connection. A reponse came in 23 seconds, but after we had timed out. Obviously this is sub-optimal... Tom Perrine & Jeff Makey ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860515115810.6.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986051507580000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@SCRC-QUABBIN.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860515115810.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 15-May-86 11:58:00 EDT Article-I.D.: FIREBIRD.860515115810.6.DCP Posted: Thu May 15 11:58:00 1986 Date-Received: Fri, 16-May-86 07:54:41 EDT References: <12950.516501992@nrtc-gremlin.northrop.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 93 Approved: tcp-ip@sri-nic.arpa Date: Wed, 14 May 86 17:46:32 -0700 From: Marshall Rose If your argument is: "having a port space of 512 distinct addresses is too small" then I doubt anyone dis-agrees in principle. On the other hand, if your argument is: "Benson and I, working on the floor for the same company, collided, so the port space is too small" Then your argument points more to a possible (mis)management problem in your company than a port scarcity problem! We were both doing independent, exploratory research of completley unrelated problem domains. Maybe we should have a number czar that is on call 24 hours a day in case somebody has a hack attack at 9:30pm (or 3am) and needs a protocol number in 5 minutes. Because my application was stream oriented it works over TCP and CHAOS. I didn't have any problem with Chaos because my protocol was called MANDELBROT and Benson's was completely different. Let's face it, 512 distinct addresses for ports probably is too small for the totality of applications that can/could use TCP. I don't think it's too small any given group of co-operating sites using TCP, though I could be convinced otherwise. Here is a list of protocols that we use at Symbolics. Some are trivial. Some work over TCP and have RFCs. All are (or were at one time or another) useful, but not critical. Sorry to bother everybody with this list, but it shows that one company has several protocols that are not all RFCs. I don't think any of the ones below are considered proprietary. That's 32+ protocols we have use for. If 16 companies or groups or implementations each have 32 different protocols, we would (a) have a tower of Babel, and (b) run out of the 512 port numbers. The tower of Babel might be needed. For example, what machines other than Suns can use the Sun net-paging protocol? "MANDELBROT" My network mandelbrot protocol and is Lisp only (it actually sends Lisp forms) "SEND" Interactive messages (ancient) "CONVERSE" Interactive messages, done much better "SMTP" (It's a byte stream protocol) "EXPAND-MAILING-LIST" (ditto) "ECHO" I think these have TCP equivalents "BABEL" "TIME" "NAME" "MAIL" Chaos version "UPTIME" Similar to TIME "QFILE" (old) LispM file protocol "NFILE" new one "FINGER" Similar to NAME, but simpler in ways "DOMAIN" The internet domain resolver stuff "NAMESPACE" Our own namespace stuff, written before the RFC "NAMESPACE-TIMESTAMP" for domains came out, and in some of our "WHO-AM-I" opinions, superior "TELNET" Specified in an RFC "SUPDUP" Specified in an RFC "TELSUP" A mixture of the two "TTYLINK" "raw" linking; no protocol. useful for connecting to Unix "3600-LOGIN" Better than all the above for talking to 3600s "PRINTER-QUEUE" Various printer queue operations "LGP-STATUS" "LGP" "LGP-QUEUE" "DOVER" "DOVER-STATUS" "CONFIGURATION" Various other useful protocols "RESET-TIME-SERVER" For machines whose clocks are off "TCP" To connect to TCP streams through a protocol gateway "NOTIFY" Information dispersal "STATUS" Network status "DUMP-ROUTING-TABLE" Topology debugging "RTAPE" Remote Tape facility Personally, I like the Berkeley method since you can just define some numbers to meet your needs. I'm not so keen on using strings or datastructures as port identifiers, though I'm sure, when ISO gets around to defining the port space for TS-users, they'll be sure to add an option for regular expressions, mandelbrots, etc. (-: /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605151604.AA01899%40bu-cs.ARPA] <1986051508041400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: root@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: re: port collisions Message-ID: <8605151604.AA01899@bu-cs.ARPA> Date: Thu, 15-May-86 12:04:14 EDT Article-I.D.: bu-cs.8605151604.AA01899 Posted: Thu May 15 12:04:14 1986 Date-Received: Fri, 16-May-86 07:55:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa I think there is a problem here. Due to obvious security reasons many of these protocols will need a low socket number and there are only 255 of those guaranteed to be available (UNIX extends that to 1023 but I don't think everyone can honor that.) Some small portion of that is already in use and if commercial trends continue I suspect many, many vendors will need a *secure* port for their products. The only solution I can think of is a super-server protocol which would listen on a single secure port and map strings to available non-secure ports indirectly (I believe the TOPS-20 IPC works something like this.) I've thought about it a few hours and it's not easy, especially when you start to take different TCP implementations into account (how exactly do I reserve and "hand-off" a port number between two unrelated processes? that's an O/S issue but I fear not generally easy.) Doesn't SUN's RPC (which I believe is in the public domain) address this issue (no pun intended)? If you say "do you seriously expect me to implement RPC and XDR just to get a port number?", I sympathize, I was only trying to find analogues for enlightenment. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605152210.AA01636%40ucbvax.Berkeley.EDU] <1986051509220000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GARY@HARVARDA.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8605152210.AA01636@ucbvax.Berkeley.EDU> Date: Thu, 15-May-86 13:22:00 EDT Article-I.D.: ucbvax.8605152210.AA01636 Posted: Thu May 15 13:22:00 1986 Date-Received: Sat, 17-May-86 04:25:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa please take my name off your mailing list.... thank gary at harvarda.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051510315400> Received: from SRI-KL.ARPA by SRI-NIC.ARPA with TCP; Thu 15 May 86 17:33:41-PDT Date: Thu 15 May 86 17:31:54-PDT From: MULHERN@SRI-KL.ARPA Subject: Re: Port Collisions To: braden@ISI-BRADEN.ARPA cc: Margulies@SCRC-YUKON.ARPA, Murray.pa@XEROX.COM, postel@USC-ISI.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "braden@isi-braden.arpa (Bob Braden)" of Wed 14 May 86 13:56:56-PDT I did work for Jon Brommeland at NAVELEX Vallejo which was sponsored by PDW-120. He did not let us contact 120 directly, and the Vallejo involvement did not turn out well, but I (and several others here) learned much about 120's systems -- NWSS, FHLT,HLT,OBS, OBU, IID, STT/TDCS and ISE. Our task was to design a local network for the 120 testbed at Patuxent River. We also reviewed the initial specifications for OBU (non-black world). This work was completed in 82/83. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605152016.AA14729%40BORAX.LCS.MIT.EDU] <1986051512164400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dab@BORAX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: port collisions Message-ID: <8605152016.AA14729@BORAX.LCS.MIT.EDU> Date: Thu, 15-May-86 16:16:44 EDT Article-I.D.: BORAX.8605152016.AA14729 Posted: Thu May 15 16:16:44 1986 Date-Received: Sat, 17-May-86 04:37:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Date: Thu, 15 May 86 12:04:14 EDT From: Ra I think there is a problem here. Due to obvious security reasons many of these protocols will need a low socket number and there are only 255 of those guaranteed to be available (UNIX extends that to 1023 but I don't think everyone can honor that.) Some small portion of that is already in use and if commercial trends continue I suspect many, many vendors will need a *secure* port for their products. -Barry Shein, Boston University As far as I've found, this belief that some ports are secure while others aren't is only implemented by Berkekley Unix. Since other IP implementations do not necessarily honor this belief, there is no security in using *secure* ports unless your network consists exclusively of machines running Berkelely Unix. David Bridgham ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605161029.AA11375%40ucbvax.Berkeley.EDU] <1986051513280000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tom@LOGICON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Redirect wars and Buterfly gateways Message-ID: <8605161029.AA11375@ucbvax.Berkeley.EDU> Date: Thu, 15-May-86 17:28:00 EDT Article-I.D.: ucbvax.8605161029.AA11375 Posted: Thu May 15 17:28:00 1986 Date-Received: Sat, 17-May-86 04:34:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa This month's issue (May) of "Mini-Micro Systems" has a blurb in the "Breakpoints" section (page 20) about a system called "Monarch", from BBN Laboratories which will have 8,192 parallel processors of an undisclosed type. In the paragraph they mention that, for those who can't wait for Monarch, BBN is shipping something called the "Butterfly" system consisting of 256 Motorola MC68020 processors working in parallel. Is this any relation to the much-alluded-to "Butterfly gateway" which is supposed to save us from the ravages of brain-dead gateways? Speaking of brain-dead gateways, we have had some more instances of the ICMP "redirect wars". This morning SRI-MILNET-GW redirected us to BBN-MILNET-GW, who redirected us back to SRI-MILNET-GW. This happened 11 times in 29 seconds while trying to establish a connection. A reponse came in 23 seconds, but after we had timed out. Obviously this is sub-optimal... Tom Perrine & Jeff Makey ----MESSAGE-END---- ----MESSAGE-BEGIN---- [14084.516553663%40nrtc-gremlin.northrop.com] <1986051515293500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@nrtc-gremlin.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <14084.516553663@nrtc-gremlin.northrop.com> Date: Thu, 15-May-86 19:29:35 EDT Article-I.D.: nrtc-gre.14084.516553663 Posted: Thu May 15 19:29:35 1986 Date-Received: Sat, 17-May-86 04:28:09 EDT References: <860515080358.4.MARGULIES@REDWING.SCRC.Symbolics.COM> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: tcp-ip@sri-nic.ARPA Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa The obviously problem with a "multiplexing port" is that you can no longer tell by looking at the TCB what protocol is being spoken. This renders programs like netstat on BSD UNIX, et. al., pretty much worthless. If we're going to expand the port space somehow, I vote we do it explicitly in the TCP headers, so it's part of the information in the TCB, rather than expand the port space covertly by exchanging the information in the TCP data. /mtr ps: of course, this is the exact opposite of what we did in rfc973 (iso transport on top of the tcp), primarily because I thought 1) keeping track of the numbers, if there ever were numbers, should be separate from the tcp port space, since the protocols probably weren't going to look anything like our good old ARM-style protocols ; and, 2), there's a good chance that we'd need more than 512 port numbers in the next three-five years. To postpone that problem, 4K port numbers were reserved; presumably, though I didn't think about it, 2K of those are for "private" use. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605152358.AA00304%40apolling.imagen.uucp] <1986051515583100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@imagen.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: C implementations of TCP/IP Message-ID: <8605152358.AA00304@apolling.imagen.uucp> Date: Thu, 15-May-86 19:58:31 EDT Article-I.D.: apolling.8605152358.AA00304 Posted: Thu May 15 19:58:31 1986 Date-Received: Sat, 17-May-86 15:52:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.dec.com Organization: The ARPA Internet Lines: 1546 Approved: tcp-ip@sri-nic.arpa Two from MIT that I know of: - The MIT PC/IP software for the IBM-PC. - The V6 Unix TCP/IP software written by Liza Martin at MIT. The alto implementation (BCPL) is also available; pieces of each of the unix packages are direct translations to C of the alto code. Both the MIT packages should be available from someone at the systems group at MIT. The only appropriate person I know of who is still (sort of) in the systems group is Jerry Saltzer. In the meantime, here is an implementation of TCP that I wrote and am willing to put in the public domain. I call it "tinytcp" after "tinybasic" and "tiny-c" -- it's a very simple TCP that accomodates a busywaiting style of coding. We use it here at Imagen to allow us to boot our image processors using arpa-ftp. There are one or two nasty hacks in the code. The worst hack is that big-endian byte ordering is assumed. Please send flames about such hacks to /dev/null. But report any bugs to me. - Geof ---------------CUT HERE------------------------------------------------ #!/bin/sh : "This is a shell archive, meaning: " : "1. Remove everything above the #! /bin/sh line. " : "2. Save the resulting test in a file. " : "3. Execute the file with /bin/sh (not csh) to create the files:" : " README" : " arp.c" : " sed.c" : " sed.h" : " tinyftp.c" : " tinytcp.c" : " tinytcp.h" : "This archive created: Thu May 15 16:43:07 PDT 1986 " echo file: README sed 's/^X//' >README << 'END-of-README' X X TinyTcp Public Domain Release X XThe files in this release contain a simple implementation of XTCP & FTP, suitable for burning into ROM. It is, in effect, Xa big hack put together in two or three days. It works for Xus, though, and you might like it, too. Warning: the code Xwas intended for a 68000, and doesn't have any byte swapping Xsupport in it. Shouldn't be too hard to add, though. X X - Geof Cooper X Imagen Corporation X [imagen!geof@decwrl.dec.com] X April 16, 1986 X XThe package requires some system support: X X clock_ValueRough() - should be a procedure that returns the current X value of a millisecond clock. The procedure is called frequently, X so that interrupts are not needed to service the clock. Our X implementation polls the real time timer and assumes that it is X called frequently enough so that it doesn't miss clock ticks (Since X the timer is only used for network timeouts, it doesn't really matter X if it does miss clock ticks, of course). Systems without a clock X could probably get by with a procedure that increments a static X variable and returns it, by adjusting the timeout constants in the X program. X X Network driver - some network interface driver is needed. A driver for a X 3Com multibus (ethernet) board is included; this board isn't made anymore X (at least not by 3Com), so you'll probably need to write a driver for the X board in your system. X X XGuide to source files: X X sed.c - Simple Ethernet Driver - Driver for 3Com multibus card. If you X have another type of Ethernet board, you can use this driver as X a template. X X sed.h - header file for the above. X X arp.c - Implementation of Address Resolution Protocol. Note that there X is no arp "mapping" per se. The higher level code (tcp, in this case) X is required to keep track of internet and ethernet addresses. X X tinytcp.c - Implementation of TCP. X X tinytcp.h - Header file for above, and for everything else. X X tinyftp.c - Implementation of FTP, only allows files to be retrieved, not sent. END-of-README echo file: arp.c sed 's/^X//' >arp.c << 'END-of-arp.c' X/* X * SAR: Simple Address Resolution Protocol Implementation X * Written by Geoffrey Cooper, September 27, 1983 X * X * This package implements a very simple version of the Plummer Address X * Resolution Protocol (RFC 826). It allows clients to resolve Internet X * addresses into Ethernet addresses, and knows how to respond to an X * address resolution request (when the transmit buffer is free). X * X * Routines: X * X * sar_CheckPacket( pb ) => 1, if ARP packet and processed, 0 otherwise X * sar_MapIn2Eth( ina, ethap ) => 1 if did it, 0 if couldn't. X * X * Copyright (C) 1983, 1986 IMAGEN Corporation X * "This code may be duplicated in whole or in part provided that [1] there X * is no commercial gain involved in the duplication, and [2] that this X * copyright notice is preserved on all copies. Any other duplication X * requires written notice of the author." X * X */ X#include "tinytcp.h" X Xsar_CheckPacket(ap) X register arp_Header *ap; X{ X register arp_Header *op; X X if ( ap->hwType != arp_TypeEther || /* have ethernet hardware, */ X ap->protType != 0x800 || /* and internet software, */ X ap->opcode != ARP_REQUEST || /* and be a resolution req. */ X ap->dstIPAddr != sin_lclINAddr /* for my addr. */ X ) return ( 0 ); /* .... or we ignore it. */ X X /* format response. */ X op = (arp_Header *)sed_FormatPacket(ap->srcEthAddr, 0x806); X op->hwType = arp_TypeEther; X op->protType = 0x800; X op->hwProtAddrLen = (sizeof(eth_HwAddress) << 8) + sizeof(in_HwAddress); X op->opcode = ARP_REPLY; X op->srcIPAddr = sin_lclINAddr; X MoveW(sed_lclEthAddr, op->srcEthAddr, sizeof(eth_HwAddress)); X ap->dstIPAddr = op->srcIPAddr; X MoveW(ap->srcEthAddr, op->dstEthAddr, sizeof(eth_HwAddress)); X X sed_Send(sizeof(arp_Header)); X X return ( 1 ); X} X X/* X * Do an address resolution bit. X */ Xsar_MapIn2Eth(ina, ethap) X longword ina; X eth_HwAddress *ethap; X{ X register arp_Header *op; X extern in_HwAddress sin_lclINAddr; X register i; X longword endTime; X longword rxMitTime; X X sed_Receive( 0 ); X endTime = clock_ValueRough() + 2000; X while ( endTime > clock_ValueRough() ) { X op = (arp_Header *)sed_FormatPacket(&sed_ethBcastAddr[0], 0x806); X op->hwType = arp_TypeEther; X op->protType = 0x800; X op->hwProtAddrLen = (sizeof(eth_HwAddress) << 8) + sizeof(in_HwAddress); X op->opcode = ARP_REQUEST; X op->srcIPAddr = sin_lclINAddr; X MoveW(sed_lclEthAddr, op->srcEthAddr, sizeof(eth_HwAddress)); X op->dstIPAddr = ina; X X /* ...and send the packet */ X sed_Send( sizeof(arp_Header) ); X X rxMitTime = clock_ValueRough() + 250; X while ( rxMitTime > clock_ValueRough() ) { X op = (arp_Header *)sed_IsPacket(); X if ( op ) { X if ( sed_CheckPacket(op, 0x806) == 1 && X op->protType == 0x800 && X op->srcIPAddr == ina && X op->opcode == ARP_REPLY ) { X MoveW(op->srcEthAddr, ethap, sizeof(eth_HwAddress)); X return ( 1 ); X } X sed_Receive(op); X } X } X } X return ( 0 ); X} END-of-arp.c echo file: sed.c sed 's/^X//' >sed.c << 'END-of-sed.c' X/* X * Ethernet Driver. X * A Very Simple set of ethernet driver primitives. The ethernet (3com Mbus) X * interface is controlled by busy-waiting, the application is handed the X * location of on-board packet buffers, and allowed to fill in the X * transmit buffer directly. The interface is entirely blocking. X * X * Written March, 1986 by Geoffrey Cooper X * X * Copyright (C) 1986, IMAGEN Corporation X * "This code may be duplicated in whole or in part provided that [1] there X * is no commercial gain involved in the duplication, and [2] that this X * copyright notice is preserved on all copies. Any other duplication X * requires written notice of the author." X * X * Primitives: X * sed_Init() -- Initialize the package X * sed_FormatPacket( destEAddr ) => location of transmit buffer X * sed_Send( pkLength ) -- send the packet that is in the transmit buffer X * sed_Receive( recBufLocation ) -- enable receiving packets. X * sed_IsPacket() => location of packet in receive buffer X * sed_CheckPacket( recBufLocation, expectedType ) X * X * Global Variables: X * sed_lclEthAddr -- Ethernet address of this host. X * sed_ethBcastAddr -- Ethernet broadcast address. X */ X X#include "tinytcp.h" X#include "sed.h" X X#define en10pages ((en10size) >> pageshift) X Xoctet *sed_va; /* virtual address of ethernet card */ Xeth_HwAddress sed_lclEthAddr; /* local ethernet address */ Xeth_HwAddress sed_ethBcastAddr; /* Ethernet broadcast address */ XBOOL sed_respondARPreq; /* controls responses to ARP req's */ Xchar bufAinUse, bufBinUse; /* tell whether bufs are in use */ X X/* X * Initialize the Ethernet Interface, and this package. Enable input on X * both buffers. X */ Xsed_Init() X{ X int recState; X register i, j; X X recState = 7; /* == mine + broad - errors */ X X /* Map the Ethernet Interface in, and initialize sed_va */ X sed_va = (octet *)SED3CVA; /* our virtual addr */ X X /* Map memory for 3Com board (must be 8k boundary) */ X /* INSERT CODE HERE */ X map_ethernet_board(); X X /* Reset the Ethernet controller */ X MECSR(sed_va) = RESET; X for (i=0; i<10; i++); /* delay a bit... */ X X /* just copy on-board ROM to on-board RAM, to use std. address */ X Move(MEAROM(sed_va), sed_lclEthAddr, 6); X Move(sed_lclEthAddr, MEARAM(sed_va), 6); X X MECSR(sed_va) |= AMSW; /* and tell board we did it */ X X /* X * and initialize the exported variable which gives the Eth broadcast X * address, for everyone else to use. X */ X for (i=0; i<3; i++) sed_ethBcastAddr[i] = 0xFFFF; X X /* accept packets addressed for us and broadcast packets */ X X MECSR(sed_va) = (MECSR(sed_va)&~PA) | recState; X X /* declare both buffers in use... */ X bufAinUse = bufBinUse = TRUE; X X} X X/* X * Format an ethernet header in the transmit buffer, and say where it is. X * Note that because of the way the 3Com interface works, we need to know X * how long the packet is before we know where to put it. The solution is X * that we format the packet at the BEGINNING of the transmit buffer, and X * later copy it (carefully) to where it belongs. Another hack would be X * to be inefficient about the size of the packet to be sent (always send X * a larger ethernet packet than you need to, but copying should be ok for X * now. X */ Xoctet * Xsed_FormatPacket( destEAddr, ethType ) X register octet *destEAddr; X{ X register octet *xMitBuf; X X xMitBuf = &((octet *)MEXBUF(sed_va))[-0x800]; X Move( destEAddr, xMitBuf, 6 ); X Move( sed_lclEthAddr, xMitBuf + 6, 6 ); X *((short *)(xMitBuf+12)) = ethType; X return ( xMitBuf+14 ); X} X X/* X * Send a packet out over the ethernet. The packet is sitting at the X * beginning of the transmit buffer. The routine returns when the X * packet has been successfully sent. X */ Xsed_Send( pkLengthInOctets ) X register int pkLengthInOctets; X{ X register octet *fromO, *toO; X register pkLength; X register csr; X X pkLengthInOctets += 14; /* account for Ethernet header */ X pkLengthInOctets = (pkLengthInOctets + 1) & (~1); X X if (pkLengthInOctets < E10P_MIN) X pkLengthInOctets = E10P_MIN; /* and min. ethernet len */ X X /* and copy the packet where it belongs */ X pkLength = pkLengthInOctets; X fromO = &((octet *)MEXBUF(sed_va))[-0x800] + pkLength; X toO = ((octet *)MEXBUF(sed_va)); X X while ( pkLength-- ) *--toO = *--fromO; X X /* send the packet */ X X MEXHDR(sed_va) = 2048 - pkLengthInOctets; X MECSR(sed_va) |= TBSW; X X /* and wait until it has really been sent. */ X X for (pkLength=0; pkLength < 15; pkLength++) { X while ( (! ((csr = MECSR(sed_va)) & JAM)) && (csr & TBSW) ) X ; X if (csr & JAM ) { X /* Ethernet Collision detected... */ X#ifdef DEBUG X printf("sed: JAM: MECSR=%x\n", csr); X#endif X MEBACK(sed_va) = clock_ValueRough(); X MECSR(sed_va) |= JAM; X } else break; X } X if ( pkLength == 15 ) SysBug("Go and Buy a New Ethernet Interface."); X X /* else we sent the packet ok. */ X} X X/* X * Enable the Ethernet interface to receive packets from the network. If X * the argument is zero, enable both buffers. If the argument is nonzero, X * take it as the address of the buffer to be enabled. X */ Xsed_Receive( recBufLocation ) X octet *recBufLocation; X{ X word enables = 0; X X if (recBufLocation == 0) { X bufAinUse = FALSE; X bufBinUse = FALSE; X enables = (ABSW | BBSW); X } X recBufLocation -= 16; X if (recBufLocation == ((octet *)MEAHDR(sed_va))) { X bufAinUse = FALSE; X enables = ABSW; X } X if (recBufLocation == ((octet *)MEBHDR(sed_va))) { X bufBinUse = FALSE; X enables = BBSW; X } X X MECSR (sed_va) |= enables; X} X X/* X * Test for the arrival of a packet on the Ethernet interface. The packet may X * arrive in either buffer A or buffer B; the location of the packet is X * returned. If no packet is returned withing 'timeout' milliseconds, X * then the routine returns zero. X * X * Note: ignores ethernet errors. may occasionally return something X * which was received in error. X */ X Xoctet * Xsed_IsPacket() X{ X register oldStatus; X register octet *pb; X X pb = 0; X if ( ! bufAinUse && (MECSR(sed_va)&ABSW) == 0 ) X pb = (octet *)MEAHDR(sed_va); X if ( ! pb && ! bufBinUse && (MECSR(sed_va)&BBSW) == 0 ) X pb = (octet *)MEBHDR(sed_va); X X if ( pb ) { X if ( ((octet *)pb) == ((octet *)MEAHDR(sed_va)) ) bufAinUse = 1; X else bufBinUse = 1; X pb += 16; /* get past the ethernet header */ X } X X return ( pb ); X} X X/* X * Check to make sure that the packet that you received was the one that X * you expected to get. X */ Xsed_CheckPacket( recBufLocation, expectedType ) X word *recBufLocation; X word expectedType; X{ X register recHeader = recBufLocation[-8]; X if ( (recHeader&R_ERROR) != 0 || X (recHeader&R_OFFSET) < E10P_MIN ) { X return ( -1 ); X } X if ( recBufLocation[-1] != expectedType ) { X return ( 0 ); X } X return (1); X} END-of-sed.c echo file: sed.h sed 's/^X//' >sed.h << 'END-of-sed.h' X/* X * Header file for very simple ethernet driver, based on 3Com Multibus X * board. X * X * Copyright (C) 1986, IMAGEN Corporation X * "This code may be duplicated in whole or in part provided that [1] there X * is no commercial gain involved in the duplication, and [2] that this X * copyright notice is preserved on all copies. Any other duplication X * requires written notice of the author." X */ X X#define en10size (8*1024) /* size of interface memory */ X#define en10pages ((en10size) >> pageshift) X#define E10P_MIN 60 /* Minimum Ethernet packet size */ X X/* X * The position of the 3Com interface in virtual memory. If we're X * Running the bootloader function, then it must be in the last 8k X * of virtual addresses. X */ X#ifdef BOOTLOADER X#define SED3CVA vm_3ComAdr /* hack, only need pb68.h if bootloader */ X#endif X#ifndef SED3CVA X#define SED3CVA 0x1c000 X#endif X X/* 10Mb Ethernet interface addresses */ X X#define MECSR(eth_va) *(word*)(((octet *) eth_va) + 0x0) X#define MEBACK(eth_va) *(word*)(((octet *) eth_va) + 0x2) X#define MEAROM(eth_va) (word*)(((octet *) eth_va) + 0x400) X#define MEARAM(eth_va) (word*)(((octet *) eth_va) + 0x600) X#define MEXHDR(eth_va) *(word*)(((octet *) eth_va) + 0x800) X#define MEXBUF(eth_va) (word*)(((octet *) eth_va) + 0x1000) X#define MEAHDR(eth_va) (word*)(((octet *) eth_va) + 0x1000) X#define MEBHDR(eth_va) (word*)(((octet *) eth_va) + 0x1800) X X/* control/status register fields */ X X#define BBSW 0x8000 /* Buffer B belongs to Network */ X#define ABSW 0x4000 /* Buffer A belongs to Network */ X#define TBSW 0x2000 /* Transmit buffer belongs to Network */ X#define JAM 0x1000 /* Set when transmit collision */ X#define AMSW 0x0800 /* X#define RBBA 0x0400 /* Oldest received packet is in B */ X/*#define UNUSED 0x0200 */ X#define RESET 0x0100 /* Reset the controller */ X#define BINT 0x0080 /* Interrupt when BBSW=>0 (packet in B) */ X#define AINT 0x0040 /* Interrupt when ABSW=>0 (packet in A) */ X#define TINT 0x0020 /* Interrupt when TBSW=>0 (transmit done) */ X#define JINT 0x0010 /* Enable interrupts when JAM=>1 */ X#define PA 0x000F /* Which packets should be received? */ X#define INTENABLS 0x00F0 X X/* X * Receiver Header Fields: X * The receiver header is the first (short) word of the receive buffer. It X * includes such information as how big the packet is, whether it was a X * broadcast, whether there was an error in receiving it, etc. X */ X X#define R_FCS 0x8000 /* fcs error */ X#define R_BCAST 0x4000 /* packet was NOT a broadcast */ X#define R_RANGE 0x2000 /* range error (size of pkt?) */ X#define R_MATCH 0x1000 /* packet is multicast (i.e., address X received is not that of the interface) */ X#define R_FRAME 0x0800 /* framing error */ X#define R_ERROR 0x8800 /* was there any error */ X#define R_OFFSET 0x07FF /* packet length + 1 word */ X Xextern octet *sed_FormatPacket(), *sed_WaitPacket(); X X#ifdef BOOTLOADER X#define ConsPrintf printf X#endif END-of-sed.h echo file: tinyftp.c sed 's/^X//' >tinyftp.c << 'END-of-tinyftp.c' X/* X * tinyftp.c - user ftp built on tinytcp.c X * X * Written March 31, 1986 by Geoffrey Cooper X * X * Copyright (C) 1986, IMAGEN Corporation X * "This code may be duplicated in whole or in part provided that [1] there X * is no commercial gain involved in the duplication, and [2] that this X * copyright notice is preserved on all copies. Any other duplication X * requires written notice of the author." X */ X#include "tinytcp.h" X Xtcp_Socket ftp_ctl, ftp_data, ftp_data2; Xbyte ftp_cmdbuf[120]; Xint ftp_cmdbufi; X Xbyte ftp_outbuf[80]; Xint ftp_outbufix, ftp_outbuflen; X Xshort ftp_rcvState; X#define ftp_StateGETCMD 0 /* get a command from the user */ X#define ftp_StateIDLE 1 /* idle connection */ X#define ftp_StateINCOMMAND 2 /* command sent, awaiting response */ X#define ftp_StateRCVRESP 3 /* received response, need more data */ X Xchar *ftp_script[7]; Xint ftp_scriptline; Xchar ftp_retrfile[80]; XBOOL ftp_echoMode; X Xftp_ctlHandler(s, dp, len) X tcp_Socket *s; X byte *dp; X int len; X{ X byte c, *bp, data[80]; X int i; X X if ( dp == 0 ) { X tcp_Abort(&ftp_data); X return; X } X X do { X i = len; X if ( i > sizeof data ) i = sizeof data; X MoveW(dp, data, i); X len -= i; X bp = data; X while ( i-- > 0 ) { X c = *bp++; X if ( c != '\r' ) { X if ( c == '\n' ) { X ftp_cmdbuf[ftp_cmdbufi] = 0; X ftp_commandLine(); X ftp_cmdbufi = 0; X } else if ( ftp_cmdbufi < (sizeof ftp_cmdbuf)-1 ) { X ftp_cmdbuf[ftp_cmdbufi++] = c; X } X } X } X } while ( len > 0 ); X} X Xftp_commandLine() X{ X printf("> %s\n", ftp_cmdbuf); X switch(ftp_rcvState) { X case ftp_StateIDLE: X if ( ftp_cmdbuf[3] == '-' ) X ftp_rcvState = ftp_StateRCVRESP; X break; X X case ftp_StateINCOMMAND: X if ( ftp_cmdbuf[3] == '-' ) X ftp_rcvState = ftp_StateRCVRESP; X case ftp_StateRCVRESP: X if ( ftp_cmdbuf[3] == ' ' ) X ftp_rcvState = ftp_StateIDLE; X break; X } X} X Xftp_Abort() X{ X tcp_Abort(&ftp_ctl); X tcp_Abort(&ftp_data); X} X X Xftp_application() X{ X char *s; X char *dp; X int i; X X i = -1; X if ( isina() ) { X i = busyina() & 0177; X#ifdef DEBUG X if ( i == ('D' & 037) ) SysBug("Pause to DDT"); X#endif X if ( i == ('C' & 037) ) { X printf("Closing...\n"); X tcp_Close(&ftp_ctl); X } X } X X switch (ftp_rcvState) { X case ftp_StateGETCMD: X getcmd:if ( i != -1 ) { X ftp_outbuf[ftp_outbuflen] = 0; X switch (i) { X case 'H' & 037: X case 0177: X if ( ftp_outbuflen > 0 ) { X ftp_outbuflen--; X printf("\010 \010"); X } X break; X X case 'R' & 037: X if ( ftp_echoMode ) X printf("\nFtpCmd> %s", ftp_outbuf); X break; X X case 033: X ftp_echoMode = ! ftp_echoMode; X break; X X case '\r': X case '\n': X busyouta('\n'); X dp = &ftp_outbuf[ftp_outbuflen]; X goto docmd; X X default: X if ( i >= ' ' && ftp_outbuflen < sizeof ftp_outbuf ) { X ftp_outbuf[ftp_outbuflen++] = i; X if ( ftp_echoMode ) busyouta(i); X } X } X } X break; X X case ftp_StateIDLE: X if ( ftp_scriptline < 0 ) { X ftp_rcvState = ftp_StateGETCMD; X ftp_echoMode = true; X ftp_outbuflen = 0; X printf("FtpCmd> "); X goto getcmd; X } X s = ftp_script[ftp_scriptline]; X if ( s == NIL ) X break; X ftp_scriptline++; X printf("%s\n", s); X dp = ftp_outbuf; X while ( *dp++ = *s++ ) ; X dp--; X docmd: *dp++ = '\r'; X *dp++ = '\n'; X ftp_outbuflen = dp - ftp_outbuf; X ftp_outbufix = 0; X ftp_rcvState = ftp_StateINCOMMAND; X /* fall through */ X case ftp_StateINCOMMAND: X i = ftp_outbuflen - ftp_outbufix; X if ( i > 0 ) { X i = tcp_Write(&ftp_ctl, &ftp_outbuf[ftp_outbufix], i); X ftp_outbufix += i; X tcp_Flush(&ftp_ctl); X } X /* fall through */ X case ftp_StateRCVRESP: X break; X } X X} X Xftp(host, fn, dataHandler) X in_HwAddress host; X char *fn; X procref dataHandler; X{ X word port; X char filecmd[80]; X X port = (sed_lclEthAddr[2] + clock_ValueRough()) | 0x8000; X X if ( fn ) { X /* set up the script for this session */ X ftp_script[0] = "user foo"; X ftp_script[1] = "pass foo"; X ftp_script[2] = "type i"; X sprintf(filecmd, "retr %s", fn); X ftp_script[3] = filecmd; X ftp_script[4] = "quit"; X ftp_script[5] = 0; X ftp_scriptline = 0; X } else { X ftp_scriptline = -1; /* interactive mode */ X ftp_echoMode = true; X } X X /* set up state variables */ X ftp_rcvState = ftp_StateRCVRESP; X ftp_cmdbufi = 0; X tcp_Listen(&ftp_data, port, dataHandler, 0); X tcp_Open(&ftp_ctl, port, host, 21, ftp_ctlHandler); X tcp(ftp_application); X} END-of-tinyftp.c echo file: tinytcp.c sed 's/^X//' >tinytcp.c << 'END-of-tinytcp.c' X/* X * tinytcp.c - Tiny Implementation of the Transmission Control Protocol X * X * Written March 28, 1986 by Geoffrey Cooper, IMAGEN Corporation. X * X * This code is a small implementation of the TCP and IP protocols, suitable X * for burning into ROM. The implementation is bare-bones and represents X * two days' coding efforts. A timer and an ethernet board are assumed. The X * implementation is based on busy-waiting, but the tcp_handler procedure X * could easily be integrated into an interrupt driven scheme. X * X * IP routing is accomplished on active opens by broadcasting the tcp SYN X * packet when ARP mapping fails. If anyone answers, the ethernet address X * used is saved for future use. This also allows IP routing on incoming X * connections. X * X * The TCP does not implement urgent pointers (easy to add), and discards X * segments that are received out of order. It ignores the received window X * and always offers a fixed window size on input (i.e., it is not flow X * controlled). X * X * Special care is taken to access the ethernet buffers only in word X * mode. This is to support boards that only allow word accesses. X * X * Copyright (C) 1986, IMAGEN Corporation X * "This code may be duplicated in whole or in part provided that [1] there X * is no commercial gain involved in the duplication, and [2] that this X * copyright notice is preserved on all copies. Any other duplication X * requires written notice of the author." X */ X X#include "tinytcp.h" X X/* X * Local IP address X */ Xin_HwAddress sin_lclINAddr; X X/* X * IP identification numbers X */ Xint tcp_id; X Xtcp_Socket *tcp_allsocs; X X/* Timer definitions */ X#define tcp_RETRANSMITTIME 1000 /* interval at which retransmitter is called */ X#define tcp_LONGTIMEOUT 31000 /* timeout for opens */ X#define tcp_TIMEOUT 10000 /* timeout during a connection */ X X#ifdef DEBUG X/* X * Primitive logging facility X */ X#define tcp_LOGPACKETS 1 /* log packet headers */ Xword tcp_logState; X#endif X X/* X * Initialize the tcp implementation X */ Xtcp_Init() X{ X extern eth_HwAddress sed_lclEthAddr; X X /* initialize ethernet interface */ X sed_Init(); X X tcp_allsocs = NIL; X#ifdef DEBUG X tcp_logState = 0; X#endif X tcp_id = 0; X X /* hack - assume the network number */ X sin_lclINAddr = 0x7d000000 + (*((longword *)&sed_lclEthAddr[1]) & 0xFFFFFF); X} X X/* X * Actively open a TCP connection to a particular destination. X */ Xtcp_Open(s, lport, ina, port, datahandler) X tcp_Socket *s; X in_HwAddress ina; X word lport, port; X procref datahandler; X{ X extern eth_HwAddress sed_ethBcastAddr; X X s->state = tcp_StateSYNSENT; X s->timeout = tcp_LONGTIMEOUT; X if ( lport == 0 ) lport = clock_ValueRough(); X s->myport = lport; X if ( ! sar_MapIn2Eth(ina, &s->hisethaddr[0]) ) { X printf("tcp_Open of 0x%x: defaulting ethernet address to broadcast\n", ina); X Move(&sed_ethBcastAddr[0], &s->hisethaddr[0], sizeof(eth_HwAddress)); X } X s->hisaddr = ina; X s->hisport = port; X s->seqnum = 0; X s->dataSize = 0; X s->flags = tcp_FlagSYN; X s->unhappy = true; X s->dataHandler = datahandler; X s->next = tcp_allsocs; X tcp_allsocs = s; X tcp_Send(s); X} X X/* X * Passive open: listen for a connection on a particular port X */ Xtcp_Listen(s, port, datahandler, timeout) X tcp_Socket *s; X word port; X procref datahandler; X{ X s->state = tcp_StateLISTEN; X if ( timeout == 0 ) s->timeout = 0x7ffffff; /* forever... */ X else s->timeout = timeout; X s->myport = port; X s->hisport = 0; X s->seqnum = 0; X s->dataSize = 0; X s->flags = 0; X s->unhappy = 0; X s->dataHandler = datahandler; X s->next = tcp_allsocs; X tcp_allsocs = s; X} X X/* X * Send a FIN on a particular port -- only works if it is open X */ Xtcp_Close(s) X tcp_Socket *s; X{ X if ( s->state == tcp_StateESTAB || s->state == tcp_StateSYNREC ) { X s->flags = tcp_FlagACK | tcp_FlagFIN; X s->state = tcp_StateFINWT1; X s->unhappy = true; X } X} X X/* X * Abort a tcp connection X */ Xtcp_Abort(s) X tcp_Socket *s; X{ X if ( s->state != tcp_StateLISTEN && s->state != tcp_StateCLOSED ) { X s->flags = tcp_FlagRST | tcp_FlagACK; X tcp_Send(s); X } X s->unhappy = 0; X s->dataSize = 0; X s->state = tcp_StateCLOSED; X s->dataHandler(s, 0, -1); X tcp_Unthread(s); X} X X/* X * Retransmitter - called periodically to perform tcp retransmissions X */ Xtcp_Retransmitter() X{ X tcp_Socket *s; X BOOL x; X X for ( s = tcp_allsocs; s; s = s->next ) { X x = false; X if ( s->dataSize > 0 || s->unhappy ) { X tcp_Send(s); X x = true; X } X if ( x || s->state != tcp_StateESTAB ) X s->timeout -= tcp_RETRANSMITTIME; X if ( s->timeout <= 0 ) { X if ( s->state == tcp_StateTIMEWT ) { X printf("Closed. \n"); X s->state = tcp_StateCLOSED; X s->dataHandler(s, 0, 0); X tcp_Unthread(s); X } else { X printf("Timeout, aborting\n"); X tcp_Abort(s); X } X } X } X} X X/* X * Unthread a socket from the socket list, if it's there X */ Xtcp_Unthread(ds) X tcp_Socket *ds; X{ X tcp_Socket *s, **sp; X X sp = &tcp_allsocs; X for (;;) { X s = *sp; X if ( s == ds ) { X *sp = s->next; X break; X } X if ( s == NIL ) break; X sp = &s->next; X } X} X X/* X * busy-wait loop for tcp. Also calls an "application proc" X */ Xtcp(application) X procref application; X{ X in_Header *ip; X longword timeout, start; X int x; X X sed_Receive(0); X X timeout = 0; X while ( tcp_allsocs ) { X start = clock_ValueRough(); X ip = sed_IsPacket(); X if ( ip == NIL ) { X if ( clock_ValueRough() > timeout ) { X tcp_Retransmitter(); X timeout = clock_ValueRough() + tcp_RETRANSMITTIME; X } X X application(); X X continue; X } X X if ( sed_CheckPacket(ip, 0x806) == 1 ) { X /* do arp */ X sar_CheckPacket(ip); X X } else if ( sed_CheckPacket(ip, 0x800) == 1 ) { X /* do IP */ X if ( ip->destination == sin_lclINAddr && X in_GetProtocol(ip) == 6 && X checksum(ip, in_GetHdrlenBytes(ip)) == 0xFFFF ) { X tcp_Handler(ip); X } X } X /* recycle buffer */ X sed_Receive(ip); X X x = clock_ValueRough() - start; X timeout -= x; X } X X return ( 1 ); X} X X/* X * Write data to a connection. X * Returns number of bytes written, == 0 when connection is not in X * established state. X */ Xtcp_Write(s, dp, len) X tcp_Socket *s; X byte *dp; X int len; X{ X int x; X X if ( s->state != tcp_StateESTAB ) len = 0; X if ( len > (x = tcp_MaxData - s->dataSize) ) len = x; X if ( len > 0 ) { X Move(dp, &s->data[s->dataSize], len); X s->dataSize += len; X tcp_Flush(s); X } X X return ( len ); X} X X/* X * Send pending data X */ Xtcp_Flush(s) X tcp_Socket *s; X{ X if ( s->dataSize > 0 ) { X s->flags |= tcp_FlagPUSH; X tcp_Send(s); X } X} X X/* X * Handler for incoming packets. X */ Xtcp_Handler(ip) X in_Header *ip; X{ X tcp_Header *tp; X tcp_PseudoHeader ph; X int len; X byte *dp; X int x, diff; X tcp_Socket *s; X word flags; X X len = in_GetHdrlenBytes(ip); X tp = (tcp_Header *)((byte *)ip + len); X len = ip->length - len; X X /* demux to active sockets */ X for ( s = tcp_allsocs; s; s = s->next ) X if ( s->hisport != 0 && X tp->dstPort == s->myport && X tp->srcPort == s->hisport && X ip->source == s->hisaddr ) break; X if ( s == NIL ) { X /* demux to passive sockets */ X for ( s = tcp_allsocs; s; s = s->next ) X if ( s->hisport == 0 && tp->dstPort == s->myport ) break; X } X if ( s == NIL ) { X#ifdef DEBUG X if ( tcp_logState & tcp_LOGPACKETS ) tcp_DumpHeader(ip, tp, "Discarding"); X#endif X return; X } X X#ifdef DEBUG X if ( tcp_logState & tcp_LOGPACKETS ) X tcp_DumpHeader(ip, tp, "Received"); X#endif X X /* save his ethernet address */ X MoveW(&((((eth_Header *)ip) - 1)->source[0]), &s->hisethaddr[0], sizeof(eth_HwAddress)); X X ph.src = ip->source; X ph.dst = ip->destination; X ph.mbz = 0; X ph.protocol = 6; X ph.length = len; X ph.checksum = checksum(tp, len); X if ( checksum(&ph, sizeof ph) != 0xffff ) X printf("bad tcp checksum, received anyway\n"); X X flags = tp->flags; X if ( flags & tcp_FlagRST ) { X printf("connection reset\n"); X s->state = tcp_StateCLOSED; X s->dataHandler(s, 0, -1); X tcp_Unthread(s); X return; X } X X switch ( s->state ) { X X case tcp_StateLISTEN: X if ( flags & tcp_FlagSYN ) { X s->acknum = tp->seqnum + 1; X s->hisport = tp->srcPort; X s->hisaddr = ip->source; X s->flags = tcp_FlagSYN | tcp_FlagACK; X tcp_Send(s); X s->state = tcp_StateSYNREC; X s->unhappy = true; X s->timeout = tcp_TIMEOUT; X printf("Syn from 0x%x#%d (seq 0x%x)\n", s->hisaddr, s->hisport, tp->seqnum); X } X break; X X case tcp_StateSYNSENT: X if ( flags & tcp_FlagSYN ) { X s->acknum++; X s->flags = tcp_FlagACK; X s->timeout = tcp_TIMEOUT; X if ( (flags & tcp_FlagACK) && tp->acknum == (s->seqnum + 1) ) { X printf("Open\n"); X s->state = tcp_StateESTAB; X s->seqnum++; X s->acknum = tp->seqnum + 1; X s->unhappy = false; X } else { X s->state = tcp_StateSYNREC; X } X } X break; X X case tcp_StateSYNREC: X if ( flags & tcp_FlagSYN ) { X s->flags = tcp_FlagSYN | tcp_FlagACK; X tcp_Send(s); X s->timeout = tcp_TIMEOUT; X printf(" retransmit of original syn\n"); X } X if ( (flags & tcp_FlagACK) && tp->acknum == (s->seqnum + 1) ) { X s->flags = tcp_FlagACK; X tcp_Send(s); X s->seqnum++; X s->unhappy = false; X s->state = tcp_StateESTAB; X s->timeout = tcp_TIMEOUT; X printf("Synack received - connection established\n"); X } X break; X X case tcp_StateESTAB: X if ( (flags & tcp_FlagACK) == 0 ) return; X /* process ack value in packet */ X diff = tp->acknum - s->seqnum; X if ( diff > 0 ) { X Move(&s->data[diff], &s->data[0], diff); X s->dataSize -= diff; X s->seqnum += diff; X } X s->flags = tcp_FlagACK; X tcp_ProcessData(s, tp, len); X break; X X case tcp_StateFINWT1: X if ( (flags & tcp_FlagACK) == 0 ) return; X diff = tp->acknum - s->seqnum - 1; X s->flags = tcp_FlagACK | tcp_FlagFIN; X if ( diff == 0 ) { X s->state = tcp_StateFINWT2; X s->flags = tcp_FlagACK; X printf("finack received.\n"); X } X tcp_ProcessData(s, tp, len); X break; X X case tcp_StateFINWT2: X s->flags = tcp_FlagACK; X tcp_ProcessData(s, tp, len); X break; X X case tcp_StateCLOSING: X if ( tp->acknum == (s->seqnum + 1) ) { X s->state = tcp_StateTIMEWT; X s->timeout = tcp_TIMEOUT; X } X break; X X case tcp_StateLASTACK: X if ( tp->acknum == (s->seqnum + 1) ) { X s->state = tcp_StateCLOSED; X s->unhappy = false; X s->dataSize = 0; X s->dataHandler(s, 0, 0); X tcp_Unthread(s); X printf("Closed. \n"); X } else { X s->flags = tcp_FlagACK | tcp_FlagFIN; X tcp_Send(s); X s->timeout = tcp_TIMEOUT; X printf("retransmitting FIN\n"); X } X break; X X case tcp_StateTIMEWT: X s->flags = tcp_FlagACK; X tcp_Send(s); X } X} X X/* X * Process the data in an incoming packet. X * Called from all states where incoming data can be received: established, X * fin-wait-1, fin-wait-2 X */ Xtcp_ProcessData(s, tp, len) X tcp_Socket *s; X tcp_Header *tp; X int len; X{ X int diff, x; X word flags; X byte *dp; X X flags = tp->flags; X diff = s->acknum - tp->seqnum; X if ( flags & tcp_FlagSYN ) diff--; X x = tcp_GetDataOffset(tp) << 2; X dp = (byte *)tp + x; X len -= x; X if ( diff >= 0 ) { X dp += diff; X len -= diff; X s->acknum += len; X s->dataHandler(s, dp, len); X if ( flags & tcp_FlagFIN ) { X s->acknum++; X#ifdef DEBUG X printf("consumed fin.\n"); X#endif X switch(s->state) { X case tcp_StateESTAB: X /* note: skip state CLOSEWT by automatically closing conn */ X x = tcp_StateLASTACK; X s->flags |= tcp_FlagFIN; X s->unhappy = true; X#ifdef DEBUG X printf("sending fin.\n"); X#endif X break; X case tcp_StateFINWT1: X x = tcp_StateCLOSING; X break; X case tcp_StateFINWT2: X x = tcp_StateTIMEWT; X break; X } X s->state = x; X } X } X s->timeout = tcp_TIMEOUT; X tcp_Send(s); X} X X/* X * Format and send an outgoing segment X */ Xtcp_Send(s) X tcp_Socket *s; X{ X tcp_PseudoHeader ph; X struct _pkt { X in_Header in; X tcp_Header tcp; X longword maxsegopt; X } *pkt; X byte *dp; X X pkt = (struct _pkt *)sed_FormatPacket(&s->hisethaddr[0], 0x800); X dp = &pkt->maxsegopt; X X pkt->in.length = sizeof(in_Header) + sizeof(tcp_Header) + s->dataSize; X X /* tcp header */ X pkt->tcp.srcPort = s->myport; X pkt->tcp.dstPort = s->hisport; X pkt->tcp.seqnum = s->seqnum; X pkt->tcp.acknum = s->acknum; X pkt->tcp.window = 1024; X pkt->tcp.flags = s->flags | 0x5000; X pkt->tcp.checksum = 0; X pkt->tcp.urgentPointer = 0; X if ( s->flags & tcp_FlagSYN ) { X pkt->tcp.flags += 0x1000; X pkt->in.length += 4; X pkt->maxsegopt = 0x02040578; /* 1400 bytes */ X dp += 4; X } X MoveW(s->data, dp, s->dataSize); X X /* internet header */ X pkt->in.vht = 0x4500; /* version 4, hdrlen 5, tos 0 */ X pkt->in.identification = tcp_id++; X pkt->in.frag = 0; X pkt->in.ttlProtocol = (250<<8) + 6; X pkt->in.checksum = 0; X pkt->in.source = sin_lclINAddr; X pkt->in.destination = s->hisaddr; X pkt->in.checksum = ~checksum(&pkt->in, sizeof(in_Header)); X X /* compute tcp checksum */ X ph.src = pkt->in.source; X ph.dst = pkt->in.destination; X ph.mbz = 0; X ph.protocol = 6; X ph.length = pkt->in.length - sizeof(in_Header); X ph.checksum = checksum(&pkt->tcp, ph.length); X pkt->tcp.checksum = ~checksum(&ph, sizeof ph); X X#ifdef DEBUG X if ( tcp_logState & tcp_LOGPACKETS ) X tcp_DumpHeader(&pkt->in, &pkt->tcp, "Sending"); X#endif X X sed_Send(pkt->in.length); X} X X/* X * Do a one's complement checksum X */ Xchecksum(dp, length) X word *dp; X int length; X{ X int len; X longword sum; X X len = length >> 1; X sum = 0; X while ( len-- > 0 ) sum += *dp++; X if ( length & 1 ) sum += (*dp & 0xFF00); X sum = (sum & 0xFFFF) + ((sum >> 16) & 0xFFFF); X sum = (sum & 0xFFFF) + ((sum >> 16) & 0xFFFF); X X return ( sum ); X} X X/* X * Dump the tcp protocol header of a packet X */ Xtcp_DumpHeader( ip, tp, mesg ) X in_Header *ip; X char *mesg; X{ X register tcp_Header *tp = (tcp_Header *)((byte *)ip + in_GetHdrlenBytes(ip)); X static char *flags[] = { "FIN", "SYN", "RST", "PUSH", "ACK", "URG" }; X int len; X word f; X X len = ip->length - ((tcp_GetDataOffset(tp) + in_GetHdrlen(ip)) << 2); X printf("TCP: %s packet:\nS: %x; D: %x; SN=%x ACK=%x W=%d DLen=%d\n", X mesg, tp->srcPort, tp->dstPort, tp->seqnum, tp->acknum, X tp->window, len); X printf("DO=%d, C=%x U=%d", X tcp_GetDataOffset(tp), tp->checksum, tp->urgentPointer); X /* output flags */ X f = tp->flags; X for ( len = 0; len < 6; len++ ) X if ( f & (1 << len) ) printf(" %s", flags[len]); X printf("\n"); X} X X/* X * Move bytes from hither to yon X */ XMove( src, dest, numbytes ) X register byte *src, *dest; X register numbytes; X{ X if ( numbytes <= 0 ) return; X if ( src < dest ) { X src += numbytes; X dest += numbytes; X do { X *--dest = *--src; X } while ( --numbytes > 0 ); X } else X do { X *dest++ = *src++; X } while ( --numbytes > 0 ); X} END-of-tinytcp.c echo file: tinytcp.h sed 's/^X//' >tinytcp.h << 'END-of-tinytcp.h' X/* X * tinytcp.h - header file for tinytcp.c X * X * Copyright (C) 1986, IMAGEN Corporation X * "This code may be duplicated in whole or in part provided that [1] there X * is no commercial gain involved in the duplication, and [2] that this X * copyright notice is preserved on all copies. Any other duplication X * requires written notice of the author." X * X * Note: the structures herein must guarantee that the X * code only performs word fetches, since the X * imagenether card doesn't accept byte accesses. X */ X X#define TRUE 1 X#define true 1 X#define FALSE 0 X#define false 0 X#define NULL 0 /* An empty value */ X#define NIL 0 /* The distinguished empty pointer */ X X/* Useful type definitions */ Xtypedef int (*procref)(); Xtypedef short BOOL; /* boolean type */ X X/* Canonically-sized data */ Xtypedef unsigned long longword; /* 32 bits */ Xtypedef unsigned short word; /* 16 bits */ Xtypedef unsigned char byte; /* 8 bits */ Xtypedef byte octet; /* 8 bits, for TCP */ X X#ifdef DDT Xextern longword MsecClock(); X#define clock_ValueRough() MsecClock() X#else Xextern longword clock_MS; X#define clock_ValueRough() clock_MS X#endif X X/* protocol address definitions */ Xtypedef longword in_HwAddress; Xtypedef word eth_HwAddress[3]; X X/* The Ethernet header */ Xtypedef struct { X eth_HwAddress destination; X eth_HwAddress source; X word type; X} eth_Header; X X/* The Internet Header: */ Xtypedef struct { X word vht; /* version, hdrlen, tos */ X word length; X word identification; X word frag; X word ttlProtocol; X word checksum; X in_HwAddress source; X in_HwAddress destination; X} in_Header; X#define in_GetVersion(ip) (((ip)->vht >> 12) & 0xf) X#define in_GetHdrlen(ip) (((ip)->vht >> 8) & 0xf) X#define in_GetHdrlenBytes(ip) (((ip)->vht >> 6) & 0x3c) X#define in_GetTos(ip) ((ip)->vht & 0xff) X X#define in_GetTTL(ip) ((ip)->ttlProtocol >> 8) X#define in_GetProtocol(ip) ((ip)->ttlProtocol & 0xff) X X Xtypedef struct { X word srcPort; X word dstPort; X longword seqnum; X longword acknum; X word flags; X word window; X word checksum; X word urgentPointer; X} tcp_Header; X X X#define tcp_FlagFIN 0x0001 X#define tcp_FlagSYN 0x0002 X#define tcp_FlagRST 0x0004 X#define tcp_FlagPUSH 0x0008 X#define tcp_FlagACK 0x0010 X#define tcp_FlagURG 0x0020 X#define tcp_FlagDO 0xF000 X#define tcp_GetDataOffset(tp) ((tp)->flags >> 12) X X/* The TCP/UDP Pseudo Header */ Xtypedef struct { X in_HwAddress src; X in_HwAddress dst; X octet mbz; X octet protocol; X word length; X word checksum; X} tcp_PseudoHeader; X X/* X * TCP states, from tcp manual. X * Note: close-wait state is bypassed by automatically closing a connection X * when a FIN is received. This is easy to undo. X */ X#define tcp_StateLISTEN 0 /* listening for connection */ X#define tcp_StateSYNSENT 1 /* syn sent, active open */ X#define tcp_StateSYNREC 2 /* syn received, synack+syn sent. */ X#define tcp_StateESTAB 3 /* established */ X#define tcp_StateFINWT1 4 /* sent FIN */ X#define tcp_StateFINWT2 5 /* sent FIN, received FINACK */ X/*#define tcp_StateCLOSEWT 6 /* received FIN waiting for close */ X#define tcp_StateCLOSING 6 /* sent FIN, received FIN (waiting for FINACK) */ X#define tcp_StateLASTACK 7 /* fin received, finack+fin sent */ X#define tcp_StateTIMEWT 8 /* dally after sending final FINACK */ X#define tcp_StateCLOSED 9 /* finack received */ X X/* X * TCP Socket definition X */ X#define tcp_MaxData 32 /* maximum bytes to buffer on output */ X Xtypedef struct _tcp_socket { X struct _tcp_socket *next; X short state; /* connection state */ X procref dataHandler; /* called with incoming data */ X eth_HwAddress hisethaddr; /* ethernet address of peer */ X in_HwAddress hisaddr; /* internet address of peer */ X word myport, hisport;/* tcp ports for this connection */ X longword acknum, seqnum; /* data ack'd and sequence num */ X int timeout; /* timeout, in milliseconds */ X BOOL unhappy; /* flag, indicates retransmitting segt's */ X word flags; /* tcp flags word for last packet sent */ X short dataSize; /* number of bytes of data to send */ X byte data[tcp_MaxData]; /* data to send */ X} tcp_Socket; X Xextern eth_HwAddress sed_lclEthAddr; Xextern eth_HwAddress sed_ethBcastAddr; Xextern in_HwAddress sin_lclINAddr; X X/* X * ARP definitions X */ X#define arp_TypeEther 1 /* ARP type of Ethernet address * X X/* harp op codes */ X#define ARP_REQUEST 1 X#define ARP_REPLY 2 X X/* X * Arp header X */ Xtypedef struct { X word hwType; X word protType; X word hwProtAddrLen; /* hw and prot addr len */ X word opcode; X eth_HwAddress srcEthAddr; X in_HwAddress srcIPAddr; X eth_HwAddress dstEthAddr; X in_HwAddress dstIPAddr; X} arp_Header; X X/* X * Ethernet interface: X * sed_WaitPacket(0) => ptr to packet (beyond eth header) X * or NIL if no packet ready. X * sed_Receive(ptr) - reenables receive on input buffer X * sed_FormatPacket(ðdest, ethtype) => ptr to packet buffer X * sed_Send(packet_length) - send the buffer last formatted. X */ Xbyte *sed_IsPacket(), *sed_FormatPacket(); END-of-tinytcp.h exit ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605161136.AA12691%40ucbvax.Berkeley.EDU] <1986051516315400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MULHERN@SRI-KL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <8605161136.AA12691@ucbvax.Berkeley.EDU> Date: Thu, 15-May-86 20:31:54 EDT Article-I.D.: ucbvax.8605161136.AA12691 Posted: Thu May 15 20:31:54 1986 Date-Received: Sat, 17-May-86 04:38:19 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa I did work for Jon Brommeland at NAVELEX Vallejo which was sponsored by PDW-120. He did not let us contact 120 directly, and the Vallejo involvement did not turn out well, but I (and several others here) learned much about 120's systems -- NWSS, FHLT,HLT,OBS, OBU, IID, STT/TDCS and ISE. Our task was to design a local network for the 120 testbed at Patuxent River. We also reviewed the initial specifications for OBU (non-black world). This work was completed in 82/83. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605190921.AA08725%40ucbvax.Berkeley.EDU] <1986051517402200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MILLS@USC-ISID.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: C implementations of TCP/IP Message-ID: <8605190921.AA08725@ucbvax.Berkeley.EDU> Date: Thu, 15-May-86 21:40:22 EDT Article-I.D.: ucbvax.8605190921.AA08725 Posted: Thu May 15 21:40:22 1986 Date-Received: Mon, 19-May-86 20:15:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa In response to the message sent Wed, 14 May 86 16:43:02 PDT from karels@monet.berkeley.edu Mike, Will you distribute the 4.2/4.3bsd TCP/IP code without a Unix source license? Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051517402201> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Thu 15 May 86 23:09:02-PDT Date: 15 May 1986 21:40:22 EDT From: MILLS@USC-ISID.ARPA Subject: Re: C implementations of TCP/IP To: karels@MONET.BERKELEY.EDU, CERF@USC-ISI.ARPA cc: tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA In response to the message sent Wed, 14 May 86 16:43:02 PDT from karels@monet.berkeley.edu Mike, Will you distribute the 4.2/4.3bsd TCP/IP code without a Unix source license? Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860516021852.205689%40MIT-MULTICS.ARPA] <1986051518180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860516021852.205689@MIT-MULTICS.ARPA> Date: Thu, 15-May-86 22:18:00 EDT Article-I.D.: MIT-MULT.860516021852.205689 Posted: Thu May 15 22:18:00 1986 Date-Received: Sat, 17-May-86 04:40:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 138 Approved: tcp-ip@sri-nic.arpa I think symbolic port names are a great idea. There are several approaches which could be taken. Possibly implementations of some of these already exist, but I don't know about them. A service multiplexing protocol: this applies to TCP but not to UDP because it relies on connections. First, reserve one low numbered TCP port for this protocol. When a user establish a connection to this server, the user sends the contact name, and optional contact arguments, in ASCII, terminated by a network newline (CRLF). The contact name is always required, and should either be registered, or long and self explanatory. CHAOS protocol allows arguments to follow the contact name, and I think we should allow this also, but they depend on the contact name and the only specification here is that they be delimited from the contact name by a space. The protocol server which listens on this TCP port should parse the contact line, look it up in the available service list, and pass off that connection as if it had just been established to the service on a reserved port. If the service is unavailable, the connection should be aborted. Note that "multiplexing" in this case is not used in the sense that is it used in IEN 90, the MUX protocol. TCBs on such systems should contain a comment field which is filled in with the service name. Then listing the TCBs can show the comment, and it won't matter that all the multiplexed services are to the multiplexed port. (Multics already does this; it makes the TCB list much easier to read.) There should be no significant performance impact in using this mechanism for TELNET, SUPDUP, SMTP, FINGER, or FTP control connections. While services used for metering, like TIME, ECHO, DISCARD, etc., can be expected to require dedicated port numbers, there should be no need to dedicate port numbers for private services thereafter. Even DOMAIN TCP connections could use multiplexing. There should be a reserved contact name which lists the available contact names. The WKS domain RR would be useful only in showing that multiplexed service is available. Perhaps this list operation should include port numbers for contacting the services, when available. A standard format should be used, so that the list is machine-readable as well as human-readable. A fly in the ointment is that some services reserve port numbers in ways that can't be multiplexed. For example, the FTP data port is port 20. A replacement for the FTP "PORT" command would be needed to eliminate this assumption. This could be addressed by modifying the FTP specification and all similar protocols if it is ever needed. But since we are doing this primarily for new protocols, they can be devised with some mechanism for negotiating additional connections, as needed, which does not require reserving ports. There are other advantages within operating systems. Services other than TCP which support streams could hand off, for example, SMTP connections in a similar manner. If an X.25 network like TYMNET is connected two sites, the operating system might permit an X.25 level 3 connection to be passed off to the SMTP server. The contact name arguments in that case might include a host name and associated password since you couldn't verify the host in the same way that you might using the Internet. An alternative or additional protocol could use a UDP service to map contact names to ports. You would send the contact name to the port as a datagram, and receive back a datagram which would indicate that 1) the service is available on port P, 2) the service is available on the multiplexed port M, or 3) that the service is unavailable. Choice #2 only applies to connection based services, but #1 and #3 could apply to either TCP or UDP, and perhaps other lower level services as well. If the query packet also contained a transport ID (e.g., 6 for TCP) or name (e.g., "TCP") then the service could be more generally applicable. This permits the equivalent of multiplexed service on UDP, a minimum cost of an extra datagram per host per service per bootload to find out what the port number is assigned to a service. It wouldn't matter that one Symbolics 3600 was running NFILE on port 57, and another on port 666, as long as they both call the service "NFILE". The UDP service could not be expected to be able to construct packets large enough to contain the names of all the available services. While in many cases they would fit, it would be unreasonable to expect that this always be the case. Rather than add complexity to this protocol it would be better to require contacting the TCP port to get the service list. The number czar (tsar?) would still be needed to hand out contact names like "TELNET" and "FINGER", and prefixes like "SYMBOLICS-". Once Benson has the "SYMBOLICS-" prefix he can hand out SYMBOLICS-PRIVATE-1, SYMBOLICS-NFILE, and so on without having to bother the czar or fear of conflict with the rest of the world. The server port number returned by UDP can have any value. The number needn't be less than 256 or 1024 to provide security. The 255 well known ports are just that: well known. If a host implements security based on port number, then it is only necessary to ensure that the port number given out by the UDP multiplexing port is secured, even if it is port FFFF (hex). The UNIX port scheme depends on the user-side port being less than 1024 to ensure that the connection is valid, not the server side port number. It is unnecessary to encode contact names in every packet, especially for TCP. A port number is sufficient to keep track of packets, and only the two parties to a conversation need know how the numbers map to services. This may not be strictly true for gateways that restrict services. Schemes that I have heard of restrict the SYN-bearing TCP packets. I'm afraid that they would have to prohibit the multiplex port. However, the UDP port translation could be used to avoid using the multiplex port for all contact names which don't require arguments. It would be nice to see an alternative to UDP that was in most ways identical to it, but which had a contact name in the packet instead of one of the port numbers. For simple transactions this would avoid the complexity of exchanging packets to get the port number before anything could be accomplished. The format of the packet would be as follows: The length would be in the pseudo header. The source port would be replaced by a transaction ID (15 bit number) and a query/response flag (one bit). The destination port would be replaced by an ASCII character string, terminated by one or two nulls to take an even number of characters. Two bytes would be reserved for an optional checksum. The rest would be data octets. If the contact name is long, the number of available data octets would be fewer than for UDP, but if the response flag were set, perhaps the contact name could be omitted from the response packet, permitting longer responses. Otherwise, the query/response flag would indicate which of the ID and the contact name is the local "port". If there already exist RFCs describing protocols which implement any of these schemes, please point them out. Otherwise, someone with immediate need for these services could write an RFC or two. All that is necessary for the Internet to generally convert to this mode of operation is that a version of Berkeley Unix get into the field which supports multiplexed service and which has user programs which attempt multiplexed operation if it is available. I think the advantages of this mode of operation will become so apparent that the rest of the network will be converted within a year or two. The time will come when both TCP and TP4 are considered hopelessly outmoded antiques. By making TCP services more flexible in this way, perhaps that can be postponed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12207098739.17.MKL%40SRI-NIC.ARPA] <1986051601160600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MKL@SRI-NIC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: port multiplexing Message-ID: <12207098739.17.MKL@SRI-NIC.ARPA> Date: Fri, 16-May-86 05:16:06 EDT Article-I.D.: SRI-NIC.12207098739.17.MKL Posted: Fri May 16 05:16:06 1986 Date-Received: Mon, 19-May-86 20:19:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa Adding a port multiplexer can present some other problems: You then have to support both the reserved well-known-sockets and the multiplexed port in order to maintain compatability with what is already in use. Then you would have to try one first and if it fails try the other. This would be silly. For example, to send mail you might first try connecting to a hosts multiplexed port. If this failed then you would have to try a direct connection to port 25. So by adding multiplexed ports you would now have to program two different ways to try and make a connection. If you try connecting to port 25 first, you either get the connection or don't, so there is no real reason to have the multiplexer support the well-known-sockets. I think a multiplexed port protocol should ONLY support "unknown-sockets" and not the "well-known-sockets". A protocol of general use would still get a reserved port number. Any private or less useful protocols that were rejected a port number would have to use the port multiplexor. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051604110000> Received: from LOGICON.ARPA by SRI-NIC.ARPA with TCP; Fri 16 May 86 12:29:13-PDT Date: 16 May 86 11:11 PDT From: Tom Perrine To: tcp-ip@sri-nic Cc: perrine@logicon.arpa Subject: Re: port collisions On the subject of picking port numbers: >Benson and I have already colided, AND WE'RE ON THE SAME FLOOR OF THE >SAME BUILDING OF THE SAME COMPANY. Since numbers don't mean anything, >we both happened to pick 666 for our private port number. I wonder if that's because they both knew that the protocols they were working on would be "devilishly difficult" to debug :-) (Sorry, I just couldn't resist...) Tom ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051606085900> Received: from LOKI.BBN.COM by SRI-NIC.ARPA with TCP; Fri 16 May 86 09:50:51-PDT To: tcp-ip@sri-nic.arpa Subject: re: port collisions Date: Fri, 16 May 86 12:48:59 -0400 From: Craig Partridge Just a side note to these discussions. Some IP protocols have only 8 bit port numbers (for example, RDP and HMP). Any general solution might think a bit about how to handle these beasties (RDP was spec'd after TCP and UDP, so there is no guarantee that new protocols will abide with the 16 bit port size unless Jon has decided to be more demanding on protocol designers). You can't casually give away many ports in a 256 port space for private use. Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605161420.AA09125%40mimsy.umd.edu] <1986051606202200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: nolan@MIMSY.UMD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Redirect wars and Buterfly gateways Message-ID: <8605161420.AA09125@mimsy.umd.edu> Date: Fri, 16-May-86 10:20:22 EDT Article-I.D.: mimsy.8605161420.AA09125 Posted: Fri May 16 10:20:22 1986 Date-Received: Mon, 19-May-86 20:12:45 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa To set the record straight on Butterflies: The Butterfly processor from BBN has nothing to do with gateways. It is a general purpose parallel processor, configurable with boards to have 16 to 256 processors. It is hosted by a Sun or Vaxen via either an Ethernet or an RS232 TIP connection. Present versions have only MC68000 chips; the MC68020 version is coming shortly. The Butterfly is programmed in C; the operating system is known as Chrysalis. nolan@maryland ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12207188416.52.ACUFF%40SUMEX-AIM.ARPA] <1986051609284300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Acuff@SUMEX-AIM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <12207188416.52.ACUFF@SUMEX-AIM.ARPA> Date: Fri, 16-May-86 13:28:43 EDT Article-I.D.: SUMEX-AI.12207188416.52.ACUFF Posted: Fri May 16 13:28:43 1986 Date-Received: Mon, 19-May-86 20:13:44 EDT References: <860516021852.205689@MIT-MULTICS.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa I like the idea of having a "port assignment service" that would map a very large space of names into port numbers for a particular host, but I would like to see "mature" protocols that have gotten to the stage of being documented in RFCs be assigned ports, thus freeing them from the extra connection overhead. Then it would be easy for protocol developers to experiment, and to make quick hacks, but the most used protocols would not be affected. -- Rich ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605191046.AA09327%40ucbvax.Berkeley.EDU] <1986051610110000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tom@LOGICON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: port collisions Message-ID: <8605191046.AA09327@ucbvax.Berkeley.EDU> Date: Fri, 16-May-86 14:11:00 EDT Article-I.D.: ucbvax.8605191046.AA09327 Posted: Fri May 16 14:11:00 1986 Date-Received: Mon, 19-May-86 20:14:08 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa On the subject of picking port numbers: >Benson and I have already colided, AND WE'RE ON THE SAME FLOOR OF THE >SAME BUILDING OF THE SAME COMPANY. Since numbers don't mean anything, >we both happened to pick 666 for our private port number. I wonder if that's because they both knew that the protocols they were working on would be "devilishly difficult" to debug :-) (Sorry, I just couldn't resist...) Tom ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605162105.AA01298%40gyre.umd.edu] <1986051613053200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@GYRE.UMD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: port collisions Message-ID: <8605162105.AA01298@gyre.umd.edu> Date: Fri, 16-May-86 17:05:32 EDT Article-I.D.: gyre.8605162105.AA01298 Posted: Fri May 16 17:05:32 1986 Date-Received: Mon, 19-May-86 20:19:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa Just to avert any confusion before it turns into a flame war: From: dab@mit-borax.arpa (David A. Bridgham) As far as I've found, this belief that some ports are secure while others aren't is only implemented by Berkekley [sic] Unix. Since other IP implementations do not necessarily honor this belief, there is no security in using *secure* ports unless your network consists exclusively of machines running Berkelely Unix. This is true, but not important. The `proper' authorisation protocol, as implemented by rcmd(), is to look for the host name in a list of `trusted' hosts first. Only after the host has been declared `trusted' is the user name considered. As long as one declares only trust*worthy* hosts (specifically those that restrict access to said ports) as trust*ed*, the protocol works. For anything more complex, of course, a public-key cryptosystem or other `better' authentication scheme is required. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605162109.AA04338%40rose.sun.uucp] <1986051613090500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: nowicki%rose@SUN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: More on Port numbers Message-ID: <8605162109.AA04338@rose.sun.uucp> Date: Fri, 16-May-86 17:09:05 EDT Article-I.D.: rose.8605162109.AA04338 Posted: Fri May 16 17:09:05 1986 Date-Received: Mon, 19-May-86 20:14:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa Doesn't SUN's RPC (which I believe is in the public domain) address this issue (no pun intended)? If you say "do you seriously expect me to implement RPC and XDR just to get a port number?", I sympathize, I was only trying to find analogues for enlightenment. Yes, Sun RPC (which was posted to mod.sources and is on the 4.3BSD tape) has a service called the "Port mapper" that listens on one well known port (number 111, officially registered as SUNRPC). Other Sun RPC services register with the port mapper, and send to this port to get other services. RPC "program numbers" are 32-bit integers, which will take a while to use up. There is a map in the Yellow Pages lookup service that maps from string name to RPC program number, so you can add new protocols without compiling their numbers in programs. There also is a Yellow Pages map for finding port numbers given a string name (like the /etc/services file in 4.x BSD). -- Bill Nowicki Sun Microsystems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605162138.AA03635%40hydra.ARPA] <1986051613380000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leiner@RIACS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Redirect wars and Buterfly gateways Message-ID: <8605162138.AA03635@hydra.ARPA> Date: Fri, 16-May-86 17:38:00 EDT Article-I.D.: hydra.8605162138.AA03635 Posted: Fri May 16 17:38:00 1986 Date-Received: Mon, 19-May-86 20:15:04 EDT References: <8605161101.AA04824@icarus.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa A little history. The butterfly processor (named because of the interconnection strategy between the multiple processors which is similar to the butterfly of the FFT) was first developed as a voice multiplexer/packetizer for the Wideband Satellite Network project and was called the voice funnel. It was then decided that it would be a good processor for the next generation of gateway and high speed packet switch for the Wideband network. When the strategic computing program started, it was then considered and pursued as a possible architecture for parallel processing in general (as opposed to dedicated use such as a packet switch). The monarch is the next generation of butterfly machine, using more extensive VLSI particularly in the interconnection switching. All of this was done by BBN under the sponsorship of DARPA. Hope this helps. Barry ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605191123.AA10213%40ucbvax.Berkeley.EDU] <1986051613561200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hinden@BBNCCV.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Redirect wars and Buterfly gateways Message-ID: <8605191123.AA10213@ucbvax.Berkeley.EDU> Date: Fri, 16-May-86 17:56:12 EDT Article-I.D.: ucbvax.8605191123.AA10213 Posted: Fri May 16 17:56:12 1986 Date-Received: Mon, 19-May-86 20:16:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa The Butterfly Gateway is real and is very related to the Butterfly Multiprocessor. As can be guessed from its name, it runs on the Butterfly Multiprocessor hardware. It was developed by BBN for DARPA and there are currently eleven installed. It is a full function routing Internet gateway with support for 1000 networks. If you would like more information, let me know and I would be happy to supply it. Regards, Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051613561201> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Fri 16 May 86 14:59:21-PDT To: Jeff Makey , Tom Perrine cc: tcp-ip@sri-nic.ARPA, hinden@BBNCCV.ARPA, nolan@maryland.ARPA Subject: Re: Redirect wars and Buterfly gateways In-reply-to: Your message of 15 May 86 14:28 PDT. Date: 16 May 86 17:56:12 EDT (Fri) From: Robert Hinden The Butterfly Gateway is real and is very related to the Butterfly Multiprocessor. As can be guessed from its name, it runs on the Butterfly Multiprocessor hardware. It was developed by BBN for DARPA and there are currently eleven installed. It is a full function routing Internet gateway with support for 1000 networks. If you would like more information, let me know and I would be happy to supply it. Regards, Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D16-May-86.21:08:03.CERF] <1986051617080000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@USC-ISI.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Redirect wars and Buterfly gateways Message-ID: <[USC-ISI.ARPA]16-May-86.21:08:03.CERF> Date: Fri, 16-May-86 21:08:00 EDT Article-I.D.: <[USC-ISI.ARPA]16-May-86.21:08:03.CERF> Posted: Fri May 16 21:08:00 1986 Date-Received: Mon, 19-May-86 20:19:45 EDT References: Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Fri 16 May 86 18:09:19-PDT Date: 16 May 1986 21:08-EDT Sender: CERF@USC-ISI.ARPA Subject: Re: Redirect wars and Buterfly gateways From: CERF@USC-ISI.ARPA To: Makey@LOGICON.ARPA, tom@LOGICON.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]16-May-86 21:08:03.CERF> In-Reply-To: The message of 15 May 86 14:28 PDT from Jeff Makey , Tom Perrine butterfly multiprocessor and butterfly gateway use the same hardware - based on multiple MC68K machines. Monarch is new technology - well over 12 months away, I would guess. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051619334800> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sat 17 May 86 02:44:26-PDT Received: by ucbvax.Berkeley.EDU (5.51/1.13) id AA00225; Sat, 17 May 86 02:33:48 PDT Date: Sat, 17 May 86 02:33:48 PDT From: ihnp4!utzoo!henry@ucbvax.Berkeley.EDU Message-Id: <8605170933.AA00225@ucbvax.Berkeley.EDU> Received: by ihnp4.ATT.COM id AA09362; 17 May 86 01:48:48 CDT (Sat) To: tcp-ip@sri-nic.arpa Subject: Re: Port Collisions References: <860514110721.9.DCP@FIREBIRD.SCRC.Symbolics.COM>, <12206734278.69.JNC@XX.LCS.MIT.EDU> > Right. What happens if you pick a name for your private > protocol that happens to be exactly the same as the name someone else > picked for their private protocol? ... > Now, if you preface all your private services with some > personal string, e.g. 'SYMBOLICS-'... Speaking from personal experience, this can work pretty well. Take a look at Usenet (I know, many of you would rather not!): we're limited to roughly a seven-character name space, but we have few collisions. By and large, people follow prefix-based naming conventions simply because it makes sense. Most of the collisions we do have are cases where somebody was being "clever" and naming sites after, say, Tolkien characters, and somebody else had the same cutesy idea. I find it striking, actually, that prefix-based naming has worked out so well in such a cramped name space on such an anarchic network. It should do nicely for port numbering, if the technical problems can be sorted out. One suggestion: pick a specific convention for separating prefix and the rest of the name. One way in which our tight name space is a real pain is that it discourages spending a character position on a delimiter. We're bound to have trouble with that some day. (Some would say we do already.) Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051703120000> Received: from SU-AI.ARPA by SRI-NIC.ARPA with TCP; Sat 17 May 86 10:14:26-PDT Date: 17 May 86 1012 PDT From: Joe Weening Subject: Port collisions: use domains! To: tcp-ip@SRI-NIC.ARPA Why not add service-name to port-number mapping to the information stored in domain nameserver databases? For example, if we decide to implement the Whizbang protocol on port 1234, then our nameserver would contain a resource record of the form Whizbang.SAIL.Stanford.EDU IN TCP-PORT 1234 Applications would refer to the protocol by name, and find the port number using a domain resolver, which will cache the information for next time. The "well-known" protocols would bypass this mechanism since their port numbers are known. Joe ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605191212.AA10916%40ucbvax.Berkeley.EDU] <1986051709120000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JJW@SU-AI.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Port collisions: use domains! Message-ID: <8605191212.AA10916@ucbvax.Berkeley.EDU> Date: Sat, 17-May-86 13:12:00 EDT Article-I.D.: ucbvax.8605191212.AA10916 Posted: Sat May 17 13:12:00 1986 Date-Received: Mon, 19-May-86 20:23:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Why not add service-name to port-number mapping to the information stored in domain nameserver databases? For example, if we decide to implement the Whizbang protocol on port 1234, then our nameserver would contain a resource record of the form Whizbang.SAIL.Stanford.EDU IN TCP-PORT 1234 Applications would refer to the protocol by name, and find the port number using a domain resolver, which will cache the information for next time. The "well-known" protocols would bypass this mechanism since their port numbers are known. Joe ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860517211919.829547%40MIT-MULTICS.ARPA] <1986051713190000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860517211919.829547@MIT-MULTICS.ARPA> Date: Sat, 17-May-86 17:19:00 EDT Article-I.D.: MIT-MULT.860517211919.829547 Posted: Sat May 17 17:19:00 1986 Date-Received: Mon, 19-May-86 20:24:16 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 63 Approved: tcp-ip@sri-nic.arpa Apparently the most controversial thing that I said in my last message was that I thought all the TCP services should be supported by the service multiplexor. The service side of the multiplexor could offer two types of service: service associated with a port number and service not associated with a port number. If no multiplexor service is associated with a port number, then the services are divided into two groups: those available by contact name, and those available by local port. It would probably be simpler to implement the service side of the multiplexor this way. However, from my point of view, if ANY service is available by both mechanisms, then the simplest way to implement it is to have the multiplexor able to access ALL well known TCP services which are available by port number. By "well known" services, I mean services where one or more server processes will accept any number of connections for the service. This has several advantages. First, I can easily imagine circumstances where for some service, access by both methods is desired, perhaps temporarily during cutover. Second, the multiplexor service list can easily list all the TCP services offered, not just those offered through the multiplexor. I would like to be able to obtain complete symbolic service lists. The biggest and most controversial advantage is that I think the Internet made a big mistake in not using contact names in general in this way. There is a simple way of proving me wrong: implement the service multiplexor and see if, once they become fairly widespread, there does not appear a definite preference for using the multiplexor for new applications indefinitely. I am not suggestion that existing user programs like TELNET be converted. I am noting my belief that this will seem like a good idea later. If this belief is mistaken, the multiplexor will still be useful for addressing the needs of stream protocol developers. Rather than implement TCBs which have no local port number associated with them, I expect that the service port multiplexor would be simplest to implement by having the server scan a list of listening TCBs. This means that every service would be available by both a port number and a multiplexor name. The services like TELNET would have "well known" port numbers from 1 to 255, while private services could be available on more obscure or even randomly chosen higher numbered ports. If all services are available both ways, it is true that there is some duplication of effort. However, the user sides need not change. In the near term, we can't expect every host to run the multiplexor, so user programs should still contact services with assigned numbers by the port numbers. Changing user programs may be considered only if the multiplxor servers of this type become nearly universal. Special operations like the service list might be implemented by passing off the connection to a service which lists the services, or by handing them in the multiplexor server. I would prefer to implement certain standard reserved operations like the service list as part of the multiplexor protocol specification, so this choice may be covered by an eventual specification. I'd rather see symbolic names than a service which maps 32 bit service numbers onto 16 bit service numbers, with the mappings from symbolic names to 32 bit numbers done at the user host, and the mapping from 32 bit to 16 bit service identifiers done at the server host. Perhaps this description of the Sun protocol is defective, but if not, why have the 32 bit numbers at all? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605180352.AA16056%40cbosgd.ATT.COM] <1986051719524700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mark@cbosgd.ATT.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: private/proprietary protocols Message-ID: <8605180352.AA16056@cbosgd.ATT.COM> Date: Sat, 17-May-86 23:52:47 EDT Article-I.D.: cbosgd.8605180352.AA16056 Posted: Sat May 17 23:52:47 1986 Date-Received: Mon, 19-May-86 20:29:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: AT&T Medical Information Systems, Columbus Lines: 61 Approved: tcp-ip@sri-nic.arpa >Personally, I think that proprietary protocols have no place in the Internet >research/military community. Please remember that TCP/IP is used throughout the world as an industry standard, it isn't just the friendly folks on the ARPANET anymore. Some of us have to deal with managers who view our every remark as intellectual property. >They are absolutely not in the best interest >of US national defense. Quite enough problems exist because the UUCP protocol >is AT&T proprietary. As a software vendor, I sympathize with the need for >trade secret and other forms of software protection. However, a deliberate >attempt to lock out interoperability with other vendors' products is bad for >the customer and ultimately bad for the vendor. I think Mark misunderstands the situation with UUCP. I am sure that AT&T has not made a deliberate effort to keep the protocol a trade secret. I don't believe they've given it any thought. I think the reason you can't just sit down and write a UUCP is that nobody at AT&T has bothered to sit down and document the protocol. (That would be a lot of work, especially to get it really right, and there's no incentive to do it.) I know of one implementation of UUCP done outside AT&T which was done by watching the line and testing against AT&T implementations, and it's in a commercial product. I don't think AT&T has any objection (but of course, if you asked them, they would have their lawyers take two years to decide.) On the other hand, the CODE implementing UUCP is certainly considered to be AT&T proprietary, as is the rest of UNIX. But how many thousands of students have seen it? >Private protocols should be discouraged as much as possible. If a protocol is >useful enough to consume part of the Internet namespace, it is useful enough >to be documented for the rest of the Internet community. My feeling is that >if there MUST be a private protocol assignment it should be "one port per >organization", and that organization should make some arrangement to identify >which of their private protocols they way (e.g. the first octet from the user >agent identifies "MIT protocol #n", or "Symbolics protocol #n", etc.) I can assure you that if AT&T were to be assigned a single TCP socket to multiplex on, things would immediately become totally unworkable. After all, there are 16 bits worth of sockets out there! That's a lot of room. By definition, any new experimental protocol invented by a commercial organization is going to be proprietary, at least initially. Getting it published as an RFC requires a fairly major management decision. Management has a lot of things to take into account in making such a decision, and the open nature of the ARPANET community is only one factor in that decision. They are concerned about things like sales, competition, and lead time on development. Good arguments can be made for the use of an industry standard protocol as a selling point, but in a new area, there probably aren't any industry standards. Depending on lots of factors, the protocol might be published quickly and pushed as an XXX standard (fill in your favoriate standards org for XXX) such as Starlan or Ethernet; it might be published later, after developers have had a chance to implement it and evaluate it (and gain lead time on competitors - IBM did this with their PC and it still created an industry standard); it might be sold under license to other vendors; or it might be kept a trade secret. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605180416.AA17067%40cbosgd.ATT.COM] <1986051720164500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mark@cbosgd.ATT.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: port collisions Message-ID: <8605180416.AA17067@cbosgd.ATT.COM> Date: Sun, 18-May-86 00:16:45 EDT Article-I.D.: cbosgd.8605180416.AA17067 Posted: Sun May 18 00:16:45 1986 Date-Received: Mon, 19-May-86 20:28:36 EDT References: <8605152016.AA14729@BORAX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: AT&T Bell Laboratories, Columbus Lines: 25 Approved: tcp-ip@sri-nic.arpa >As far as I've found, this belief that some ports are secure while >others aren't is only implemented by Berkekley Unix. Since other IP >implementations do not necessarily honor this belief, there is no >security in using *secure* ports unless your network consists >exclusively of machines running Berkelely Unix. I wouldn't even go that far. Even if your network is all based on the UNIX conventions (the System V product is the same at Berkeley) you still don't really have much security. You have to trust the super users of all the systems on your network, and keep the cable physically secure. There are enough cheap PCs running UNIX these days that any user with a PC can break in with a little cleverness. Many protocols depend on higher levels of security, e.g. FTP uses a password on every connection. I won't claim that there aren't security problems here, either, but the point is that for many applications, magic numbers like 255 or 1024 don't mean much. As far as I'm concerned, I can choose any 16 bit number. In fact, our current protocol being developed uses port 1624 and we're quite happy. Nonetheless, I hope to reserve the port number to avoid a possible random future collision. Of course, we will have some sort of management decision about publishing our protocol before we can publish it. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D18-May-86.05:48:54.CERF] <1986051801480000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: CERF@USC-ISI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Redirect wars and Buterfly gateways Message-ID: <[USC-ISI.ARPA]18-May-86.05:48:54.CERF> Date: Sun, 18-May-86 05:48:00 EDT Article-I.D.: <[USC-ISI.ARPA]18-May-86.05:48:54.CERF> Posted: Sun May 18 05:48:00 1986 Date-Received: Mon, 19-May-86 06:23:23 EDT References: <8605161420.AA09125@mimsy.umd.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa John, you leave the impression that the Butterfly Gateway has nothing to do with butterfly multiprocessor! The multiprocessor is indeed a general purpose machine. It has been used by BBN to build a more powerful internet gateway. Clearly, it can be used for other things. Lincoln Labs did a very fast FFT implementation using a 16 processor version, I believe. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12207836738.33.HEDRICK%40RED.RUTGERS.EDU] <1986051820500300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: surprising property of ICMP redirect on Unix Message-ID: <12207836738.33.HEDRICK@RED.RUTGERS.EDU> Date: Mon, 19-May-86 00:50:03 EDT Article-I.D.: RED.12207836738.33.HEDRICK Posted: Mon May 19 00:50:03 1986 Date-Received: Tue, 20-May-86 01:17:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa I have discovered, much to my surprise, that on 4.2 (at least on the Pyramid and Sun) the system will accept an ICMP redirect from anybody and act on it. We have used this feature to good effect a few times, when the core gateways lose track of us. We have a program redirect that will send an arbitrary ICMP redirect to an arbitrary host. We can often use this to put an entry for our gateway into a foreign host's routing table, and then establish connections with them. More usefully, I intend to use this in our local Ethernet gateways to set up default routing entries pointing to that gateway. We are getting so many Unix systems, managed by so many turk... er... inexperienced system managers, that we want it to be possible for us to get routing going without any action on the part of the system manager. We believe that we can broadcast an ICMP redirect establishing a routing for host 0 (default) to our gateway. I have verified that this works when it is not a broadcast, but have not yet had a chance to try the broadcast form. I think that if we do this often enough to prevent the entry from being purged by routed, we will get the effect we want. (Actually, routed should not be running on any of our hosts, but there are enough ... er ... inexperienced system managers around that I am sure it is being run on many of our hosts.) If someone sets up a different default gateway for themselves, our broadcast will cause no trouble, since a second default entry has no effect. (Actually, it is probably a bug that 4.2 creates a second entry rather than changing the information in the first one.) This is all very convenient for us, but it does seem to be a bug. I hope that by the time the bug is fixed, the gateway committee will have come up with a better way to accomplish this, and it will have been implemented by all of our Unix vendors. (say about 1996.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605191011.AA09090%40ucbvax.Berkeley.EDU] <1986051902133600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@LOKI.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: re: port collisions Message-ID: <8605191011.AA09090@ucbvax.Berkeley.EDU> Date: Mon, 19-May-86 06:13:36 EDT Article-I.D.: ucbvax.8605191011.AA09090 Posted: Mon May 19 06:13:36 1986 Date-Received: Mon, 19-May-86 20:13:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Just a side note to these discussions. Some IP protocols have only 8 bit port numbers (for example, RDP and HMP). Any general solution might think a bit about how to handle these beasties (RDP was spec'd after TCP and UDP, so there is no guarantee that new protocols will abide with the 16 bit port size unless Jon has decided to be more demanding on protocol designers). You can't casually give away many ports in a 256 port space for private use. Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860519072643.7.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986051903260000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SCRC-YUKON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: re: port collisions Message-ID: <860519072643.7.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Mon, 19-May-86 07:26:00 EDT Article-I.D.: REDWING.860519072643.7.MARGULIES Posted: Mon May 19 07:26:00 1986 Date-Received: Tue, 20-May-86 20:11:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa Date: Thu, 15 May 86 22:23 PDT From: Provan@LLL-MFE.ARPA just out of curiousity, why is it so important that you not publish your protocol as an RFC? is it just secret and yo udon't want it to be copied or is there soem other reason? just so my cards are on the table, i do work for a private, for profit, TCP protocol development firm, so be sure not to give me any secrets. At this time, we have no protocols that we with to treat as proprietary. We do have protocols that are complex and not seperately documented. Commented Lisp code is clear to those who have to maintain the works. To go back and write an RFC just to get a port number is a lot of work, since we don't need it and I imagine that no one else will ever use these protocols. The importance of avioding RFC's is that as a vendor it makes us uncomfortable to have to interact with something like a number czar to extend our product. It introduces unpredictable timing and adds work-load. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [18371.516612371%40nrtc-gremlin.northrop.com] <1986051903315900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@nrtc-gremlin.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <18371.516612371@nrtc-gremlin.northrop.com> Date: Mon, 19-May-86 07:31:59 EDT Article-I.D.: nrtc-gre.18371.516612371 Posted: Mon May 19 07:31:59 1986 Date-Received: Mon, 19-May-86 20:16:29 EDT References: <860515115810.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: tcp-ip@sri-nic.ARPA Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa I'm not going to get into an argument about how people doing "independent, exploratory research of completely unrelated problem domains" should interact with a numbers czar on call 24-hours a day. That's silly, right? But wouldn't it be okay to have a tacit agreement between people doing development work about the port space being used for "independent, exploratory research of completely unrelated problem domains" is divided up? (i.e., Benson's group gets 600-699, David's group gets 700-799, etc., etc.). No matter how complex you make the port space (e.g., go from 16-bit integers to null-terminated strings of arbitrary length), you will still run into collisions. There has to be some authority somewhere which maintains a registry, binding on all parties, which assigns protocols to the port space. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860519074440.9.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986051903440000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SCRC-YUKON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Port Multiplexing Details Message-ID: <860519074440.9.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Mon, 19-May-86 07:44:00 EDT Article-I.D.: REDWING.860519074440.9.MARGULIES Posted: Mon May 19 07:44:00 1986 Date-Received: Tue, 20-May-86 20:12:20 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@sri-nic.arpa I have been thinking about how the port multiplexing protocol might work. Part of it seems simple enough, but part does not. For TCP, the following sketch seems easy enough: Given a TCP port for a NAMED-TCP-SERVICE service, you connect to that port, and send the name of the service you want followed by a CRLF. If the service exists, your connection is handed off to it. If not, the connecting is closed. Server implementions are welcome to mark the TCB with the service name. Conceptually, note that there need not be any numeric port number associated with the protocol at all. Some implementations may choose to implement this as a mapping from names to ports. It is particularly useful for the port used to vary, so that no explicit configuration is needed to avoid collisions between protocols. For UDP, the problem is harder. In the CHAOS protocol, the datagram equivalent carries a protocol name. However, it dosen't carry any data. Having UDP packets include a protocol name would none the less be the most elegant. I fear that it won't be practical. It would probably be necessary to invent UDP-2 as a full-fledged protocol that stored the name-length in the header. The weaker alternative is a UDP service that converts a protocol name into a port number. The problem here is the lifetime of the resulting information. If the mapping from names to numbers has to be permanent, then each server implementation has to have a way to maintain a permanent data base of the assignments, which would be a shame. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051910075200> Received: from SRI-KL.ARPA by SRI-NIC.ARPA with TCP; Mon 19 May 86 17:09:23-PDT Date: Mon 19 May 86 17:07:52-PDT From: MULHERN@SRI-KL.ARPA Subject: Re: Port Collisions To: braden@ISI-BRADEN.ARPA, Margulies@SCRC-YUKON.ARPA, Murray.pa@XEROX.COM, postel@USC-ISI.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "MULHERN@SRI-KL.ARPA" of Fri 16 May 86 05:08:28-PDT sorry for my previous message -- please ignor it ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051912042600> Received: from harvard.HARVARD.EDU by SRI-NIC.ARPA with TCP; Mon 19 May 86 17:23:59-PDT Received: from localhost by harvard.HARVARD.EDU; Mon, 19 May 86 20:24:30 EDT To: JDELSIGNORE@F.BBN.COM Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: IF-11Q/1822 Device Driver In-Reply-To: Your message of 19 May 86 16:09:00 EDT. <[F.BBN.COM]19-May-86 16:09:16.JDELSIGNORE> Date: Mon, 19 May 86 20:24:26 -0500 From: /Steve Dyer I might mention that the combination of a Unibus LH-DH/11 and an Able Qniverter for your MicroVAX would do quite nicely, and will run 'out of the box' with the standard 4.2/Ultrix if_acc.c driver. This is especially attractive because no UNIBUS backplane is needed, just a UNIBUS cable from the Qniverter into the LH/DH-11. Perhaps it's not cost-effective for wholly new systems, but it's a great way to avoid trashing newly obsoleted LH/DH-11's when your VAX750's and VAX780's are upgraded to MicroVAX-II's. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BF.BBN.COM%5D19-May-86.16:09:16.JDELSIGNORE] <1986051912090000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JDELSIGNORE@F.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: IF-11Q/1822 Device Driver Message-ID: <[F.BBN.COM]19-May-86.16:09:16.JDELSIGNORE> Date: Mon, 19-May-86 16:09:00 EDT Article-I.D.: <[F.BBN.COM]19-May-86.16:09:16.JDELSIGNORE> Posted: Mon May 19 16:09:00 1986 Date-Received: Tue, 20-May-86 20:13:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Does any out there have a device driver for an IF-11Q/1822? The IF-11Q/1822 sold by ACC is composed of an XQ/1822 board and an MDMA board. I'm planning on installing the boards in the QBUS of a MicroVAX II running Ultrix. The boards are setup to do Distant Host to an ARPANET IMP. Thanks, John DelSignore JDELSIGNORE@F.BBN.COM P.S. Please respond to me directly as I am not on this mailing list. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051912090001> Received: from F.BBN.COM by SRI-NIC.ARPA with TCP; Mon 19 May 86 13:10:56-PDT Date: 19 May 1986 16:09-EDT Sender: JDELSIGNORE@F.BBN.COM Subject: IF-11Q/1822 Device Driver From: JDELSIGNORE@F.BBN.COM To: tcp-ip@SRI-NIC.ARPA Cc: JDELSIGNORE@F.BBN.COM Message-ID: <[F.BBN.COM]19-May-86 16:09:16.JDELSIGNORE> Does any out there have a device driver for an IF-11Q/1822? The IF-11Q/1822 sold by ACC is composed of an XQ/1822 board and an MDMA board. I'm planning on installing the boards in the QBUS of a MicroVAX II running Ultrix. The boards are setup to do Distant Host to an ARPANET IMP. Thanks, John DelSignore JDELSIGNORE@F.BBN.COM P.S. Please respond to me directly as I am not on this mailing list. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860519202446.210131%40MIT-MULTICS.ARPA] <1986051912240000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Multiplexing Details Message-ID: <860519202446.210131@MIT-MULTICS.ARPA> Date: Mon, 19-May-86 16:24:00 EDT Article-I.D.: MIT-MULT.860519202446.210131 Posted: Mon May 19 16:24:00 1986 Date-Received: Tue, 20-May-86 20:17:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 81 Approved: tcp-ip@sri-nic.arpa Concerning Benson Margulies' comments on NAMED-TCP-SERVICE: You can't just close the connection if the service is not implemented, because the TCP close is a half-channel close. I really think you must abort the connection, sending an RST packet, to indicate totally unambiguously that the service is unavailable. Consider the timing windows if you use a closing strategy: the user side sends the protocol name to NAMED-TCP-SERVICE, and then passes the connection to the protocol user program. Perhaps it waits for the server's TCP to acknowledge the name bytes. The server receives the name, and the service is unavailable. It closes the connection. The user side gets the close but is already in the protocol user code. This could be surprising; it might even have some other interpretation if the service multiplexor is used for some existing service. When an abort is used instead, this more closely resembles the response of a system which doesn't implement the service. If you try to contact a TCP which has nothing listening on a port, the connection is effectively aborted. Granted, it was never established, but a RST packet is a RST packet. A cleaner alternative is to have some positive acknowledgement. For example, the server could send OK, DOWN, or UNKNOWN back, followed by a CRLF. The disadvantage of this is the extra overhead of the reply. If you are lucky, the reply data gets piggybacked on the name acknowledgement, and the reply acknowledgement gets piggybacked on the first packet of the user program. Long live UDP-2. My proposal for this used a null-terminated string on the theory that it constitutes encouragement to use the UDP-2 protocol only for one shot single-query single-response datagram exchanges. This was probably not clever of me. By having a single length byte, you can hash very nicely on length and first character. I don't believe that more than one length byte is needed, but perhaps one or two high bits could be swiped as flags if 127 or 63 is acceptable as the maximum length of a protocol name. I still think that the name field should be an even number of bytes long because a number of machines like their 16 bit fields aligned. The spec should thus include a pad byte for odd length names. There is still the problem of designating the other end of the transaction. When you send a query the service name is equivalent to the foreign port; when sending a reply, the service name is the local port. Either both ports must be named, or there will have to be some other way of distinguishing queries from replies. I really don't like using two names, but perhaps that is best. I would prefer service name, transaction ID, and a query/reply flag. The transaction ID would be assigned by the querying host, and for many protocols ignored by the server except to send it back in the reply. Uniqueness might be required in some cases, but is only needed for a given host pair and service name, just as the port number would be. The extra space taken by the name combined with the packet size limits restricts the amount of data in the datagram. For UDP, I have heard suggested maximum packet sizes of 512 bytes, although you can send real jumbograms between some implementations using fragmentation. By requiring that transaction IDs be unique over host pairs (during some TTL (time to live)), the service name could be omitted from reply packets. If this seems ugly, how about a flag in the request packet indicating whether it is permissible to omit the service name from the reply. If the flag is still set in the reply, there is no service name. If the UDP port lookup service is written, a TTL field could be included in the reply. Some user sides might ignore the TTL and look up every time they had a transaction. For simple exchanges this doubles the overhead. Hosts with a permanent database could return very long times to live; and long TTLs would be the rule when servers permitted looking up permanently assigned values like TELNET => 23. When the port numbers are assigned on a per-bootload basis, or even more often, TTL values like one minute could be used to allow for system crashes or service restarts. The UDP service might be useful for protocols other than TCP. A request packet could include the protocol ID and the name of the service. The reply could begin with the request and add the port number and TTL. Perhaps the port number could be at the end so that protocols could have port numbers more than 16 bits long. I think it is reasonable to refine all three proposals. I fear that there will be few takers for UDP-2. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605192112.AA24302%40sri-spam.arpa] <1986051913120000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gds@SRI-SPAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Redirect wars and Buterfly gateways Message-ID: <8605192112.AA24302@sri-spam.arpa> Date: Mon, 19-May-86 17:12:00 EDT Article-I.D.: sri-spam.8605192112.AA24302 Posted: Mon May 19 17:12:00 1986 Date-Received: Tue, 20-May-86 20:19:55 EDT References: <8605161029.AA11375@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 56 Approved: tcp-ip@sri-nic.arpa > From: tom@LOGICON.ARPA (Jeff Makey , Tom Perrine) > Speaking of brain-dead gateways, we have had some more instances of the > ICMP "redirect wars". This morning SRI-MILNET-GW redirected us to > BBN-MILNET-GW, who redirected us back to SRI-MILNET-GW. This happened > 11 times in 29 seconds while trying to establish a connection. > A reponse came in 23 seconds, but after we had timed out. This happens to me also. Here's a sample netstat -r from sri-spam.arpa (10.2.0.107/192.5.38.3). It seems that our default gateway does not always know how to get cross-net ... Routing tables Destination Gateway Flags Refcnt Use SWS pm Interface default 10.1.0.107 UG 0 25 75 0 imp0 su-net-temp sri-milnet-gw.a UG 0 1030 75 0 imp0 su-net-temp isi-gateway.arp UG 0 1027 75 0 imp0 su-net-temp stanford-gatewa UG 0 6071 75 0 imp0 su-net-temp hazeltine-gw.ar UG 0 3 75 0 imp0 su-net-temp sac-milnet-gw.a UG 0 3 75 0 imp0 su-net-temp sri-gw.arpa UG 0 4 75 0 imp0 su-net-temp lbl-milnet-gw.a UG 0 2 75 0 imp0 su-net-temp bbn-milnet-gw.a UG 0 4 75 0 imp0 su-net-temp bbnnet2-arpanet UG 0 4 75 0 imp0 su-net-temp bbn-van-gw.arpa UG 0 2 75 0 imp0 su-net-temp crc-gw.arpa UG 0 1 75 0 imp0 su-net-temp bbn-cronus-gw.a UG 0 2 75 0 imp0 su-net-temp isi-milnet-gw.a UG 0 1 75 0 imp0 su-net-temp sri-csl-gw.arpa UG 0 2 75 0 imp0 su-net-temp bbn-net-gateway UG 0 2 75 0 imp0 su-net-temp dcec-milnet-gw. UG 0 1 75 0 imp0 Note the highest use count for the su-net-temp net is for stanford-gateway, which is as it should be. Some of the other gateways mentioned are a little skeptical -- why would multiple gateways at BBN be involved in what should be a decision strictly made in California? One question is how your host handles redirects. In 4.2, if there are multiple gateways to the same destination, it attempts to share the load between the two, by taking the lowest use count. I have discovered situations in which this may not be ideal. 4.3 attempts to be more flexible by taking the route from the last redirect, and notifying any connections of the route change (this is done in 4.2 BBN also). There is a short time in between the issuance of the redirect and the route change for the connection in which the old route might be used, which could cause a flurry of redirects. I'd like to know how yours (and others) IP routing implementations handle these sort of situations. (I'd especially like to hear from the "hosts should be dumb, gateways should be smart" folks.) Back to the original topic, though, I have noticed similar behavior going between sri-milnet-gw.arpa and bbn-milnet-gw.arpa for a lot of connections I make (aside from the above, this happens for the rutgers and mit-temp networks). --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051913180000> Mail-From: STJOHNS created at 19-May-86 20:19:34 Date: 19 May 1986 20:18-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Port Multiplexing Details From: STJOHNS@SRI-NIC.ARPA To: JSLove@MIT-MULTICS.ARPA Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]19-May-86 20:18:38.STJOHNS> In-Reply-To: <860519202446.210131@MIT-MULTICS.ARPA> Let's try and make this as simple as possible, at least for the TCP side. I haven't taken a look at the UDP stuff yet, but there may be a totally seperate solution. Having yielded to the original point that a multiplexing port is necessary, I went back and took a look at the spec and came up with the following: 1) Assign a standard TCP port for a Contact by Name server. 2) Define a TCP option - Contact Name, give is some reasonable maximum. (32 chars? 3) The Contact Name option is only valid in a packet containing a SYN. (Just like the max seg size option). 4) Multiplexing is still done at the TCP level, based on ports and host addresses. In fact, once the connection is open, there is no difference in the way it is handled. Looking at the implementations I am familiar with (Multics, UNIX), this shouldn't be difficult to implement at all. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605200246.AA24546%40ucbvax.Berkeley.EDU] <1986051913445000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MILLS@USC-ISID.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: surprising property of ICMP redirect on Unix Message-ID: <8605200246.AA24546@ucbvax.Berkeley.EDU> Date: Mon, 19-May-86 17:44:50 EDT Article-I.D.: ucbvax.8605200246.AA24546 Posted: Mon May 19 17:44:50 1986 Date-Received: Tue, 20-May-86 20:20:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa In response to the message sent 19 May 86 00:50:03 EDT from HEDRICK@RED.RUTGERS.EDU Charles, While I have ample sympathy with your routing problems in the local environment, I sure would like to discourage use of ICMP redirects in lieu of something more robust. The danger of accidental and/or malicious abuse, not to mention what happens when the bug is "fixed," would seem to argue against the scheme in the first place. Several of us have been scratching on some sort of gateway requirements model which, if it were adopted, might preclude your scheme in the interests of robustness. Your comments on Appendix A of RFC-981 would be much appreciated. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051913445001> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Mon 19 May 86 14:46:19-PDT Date: 19 May 1986 17:44:50 EDT From: MILLS@USC-ISID.ARPA Subject: Re: surprising property of ICMP redirect on Unix To: HEDRICK@RED.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA cc: MILLS@USC-ISID.ARPA In response to the message sent 19 May 86 00:50:03 EDT from HEDRICK@RED.RUTGERS.EDU Charles, While I have ample sympathy with your routing problems in the local environment, I sure would like to discourage use of ICMP redirects in lieu of something more robust. The danger of accidental and/or malicious abuse, not to mention what happens when the bug is "fixed," would seem to argue against the scheme in the first place. Several of us have been scratching on some sort of gateway requirements model which, if it were adopted, might preclude your scheme in the interests of robustness. Your comments on Appendix A of RFC-981 would be much appreciated. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605200258.AA24714%40ucbvax.Berkeley.EDU] <1986051916075200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MULHERN@SRI-KL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <8605200258.AA24714@ucbvax.Berkeley.EDU> Date: Mon, 19-May-86 20:07:52 EDT Article-I.D.: ucbvax.8605200258.AA24714 Posted: Mon May 19 20:07:52 1986 Date-Received: Tue, 20-May-86 20:21:01 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 Approved: tcp-ip@sri-nic.arpa sorry for my previous message -- please ignor it ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12208052003.18.GROSSMAN%40SU-SIERRA.ARPA] <1986051916323200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GROSSMAN@SU-SIERRA.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Port collisions continued/Service naming Message-ID: <12208052003.18.GROSSMAN@SU-SIERRA.ARPA> Date: Mon, 19-May-86 20:32:32 EDT Article-I.D.: SU-SIERR.12208052003.18.GROSSMAN Posted: Mon May 19 20:32:32 1986 Date-Received: Tue, 20-May-86 20:32:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 72 Approved: tcp-ip@sri-nic.arpa DECnet solved this problem a long time ago. Here is what it does: In DECnet, the SYN message (called a CI in DECnet) can contain one of the following for both the destination and source ports: 1) A numeric service id (ala the FTP, TELNET, etc known ports). 2) A string service id (usually called a process name). 3) A PPN and a string service ID. This data is actually carried inside the CI message just as though it was user data. The point is that the desired service is specified by a string of bytes of (almost) arbitrary length and format in the normal data bucket within the message. By contrast, TCP describes the desired service by using some bytes from the port number of the packet, which is very small and inflexible compared to the aforementioned scheme. This means that the port numbers used in DECnet have no intrinsic meaning (other than to uniquely identify this logical link). Once DECnet has made a connection, there is no way to tell what type of service is being used over a logical link. With respect to secure services, DECnet implementations are supposed to only allow privileged people to offer services for service types 1-128. In addition, only privileged people are allowed to use a different PPN from their own in the source descriptor type. I don't beleive that any DECnet implementations currently impose any restrictions on the string service ID text. But it would be easy to add. Note that the format type is carried along in the CI message prefixed to the data that it is describing. Currently, only 3 format types are defined. It would be trivial to add more if they were deemed necessary. I think that adding this to TCP could be done fairly easily. One way to do it would be to create a new option: Kind Length Meaning ---- ------ ------- 3 -- Service ID If this option is present, then it communicates the name of the service that the user desires. The format of the service name is TBD... This option must only be sent in the initial connection request (i.e., in segments with the SYN control bit set). The only important thing about the Service ID is that it should be of arbitrary length, and allow for multiple (but well specified) formats by using a format type byte in the beginning of the data. Another way to put this into TCP would be to create a new control bit: SID: Service ID If this flag is on, then the data segment of the datagram contains a service name string. The format and restrictions on this would be the same as for the option described above. Now for the question of backwards compatibility. Lets say that old TCPs were allowed to just ignore this option/SID bit. Then senders would be able to ensure connections by making SYNs that used BOTH a known port AND the Service ID option/SID bit. The one bugaboo that this has is that TCPs that support the Service ID option/bit would have to be careful about avoiding "known ports" unless they really mean to use them for their intended purpose. A way around this would be to create another flag called the KP (Known Port (Kitchen Patrol :-)) flag. If this is set, you are using a known port, otherwise the port is just a random number. I would desperately urge people to come up with a better way than this flag. Just another point 'o view, Stu Grossman ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605200441.AA26419%40ucbvax.Berkeley.EDU] <1986051918325500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mike@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: [domiller@lognet2.ARPA (Donald G. Miller): HP 3000] Message-ID: <8605200441.AA26419@ucbvax.Berkeley.EDU> Date: Mon, 19-May-86 22:32:55 EDT Article-I.D.: ucbvax.8605200441.AA26419 Posted: Mon May 19 22:32:55 1986 Date-Received: Tue, 20-May-86 20:33:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa Contact Skeet Steffey . WSMR has been doing some neat stuff with TCP for HP machines. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986051918325501> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Mon 19 May 86 19:36:12-PDT Date: Mon, 19 May 86 22:32:55 EDT From: Mike Muuss To: AFDDN.BEACH@gunter-adam.arpa, domiller@lognet2.arpa cc: tcp-ip@sri-nic.arpa Subject: Re: [domiller@lognet2.ARPA (Donald G. Miller): HP 3000] Contact Skeet Steffey . WSMR has been doing some neat stuff with TCP for HP machines. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BSRI-NIC.ARPA%5D19-May-86.20:18:38.STJOHNS] <1986051919180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Multiplexing Details Message-ID: <[SRI-NIC.ARPA]19-May-86.20:18:38.STJOHNS> Date: Mon, 19-May-86 23:18:00 EDT Article-I.D.: <[SRI-NIC.ARPA]19-May-86.20:18:38.STJOHNS> Posted: Mon May 19 23:18:00 1986 Date-Received: Tue, 20-May-86 20:42:42 EDT References: <860519202446.210131@MIT-MULTICS.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Let's try and make this as simple as possible, at least for the TCP side. I haven't taken a look at the UDP stuff yet, but there may be a totally seperate solution. Having yielded to the original point that a multiplexing port is necessary, I went back and took a look at the spec and came up with the following: 1) Assign a standard TCP port for a Contact by Name server. 2) Define a TCP option - Contact Name, give is some reasonable maximum. (32 chars? 3) The Contact Name option is only valid in a packet containing a SYN. (Just like the max seg size option). 4) Multiplexing is still done at the TCP level, based on ports and host addresses. In fact, once the connection is open, there is no difference in the way it is handled. Looking at the implementations I am familiar with (Multics, UNIX), this shouldn't be difficult to implement at all. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605200349.AA25547%40ucbvax.Berkeley.EDU] <1986051919502900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dyer@HARVARD.HARVARD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: IF-11Q/1822 Device Driver Message-ID: <8605200349.AA25547@ucbvax.Berkeley.EDU> Date: Mon, 19-May-86 23:50:29 EDT Article-I.D.: ucbvax.8605200349.AA25547 Posted: Mon May 19 23:50:29 1986 Date-Received: Tue, 20-May-86 20:52:11 EDT References: <[F.BBN.COM]19-May-86.16:09:16.JDELSIGNORE> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa I might mention that the combination of a Unibus LH-DH/11 and an Able Qniverter for your MicroVAX would do quite nicely, and will run 'out of the box' with the standard 4.2/Ultrix if_acc.c driver. This is especially attractive because no UNIBUS backplane is needed, just a UNIBUS cable from the Qniverter into the LH/DH-11. Perhaps it's not cost-effective for wholly new systems, but it's a great way to avoid trashing newly obsoleted LH/DH-11's when your VAX750's and VAX780's are upgraded to MicroVAX-II's. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605201933.AA13595%40Godot.Think.Com] <1986052011335100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bruce@THINK.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: 4.2bsd gateways Message-ID: <8605201933.AA13595@Godot.Think.Com> Date: Tue, 20-May-86 15:33:51 EDT Article-I.D.: Godot.8605201933.AA13595 Posted: Tue May 20 15:33:51 1986 Date-Received: Wed, 21-May-86 01:14:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa I have heard many things about deficiencies of 4.2bsd as internet gateways. I know some of these involve old bugs which I have fixed in our kernel, and some are just unimplemented (like sending ICMP redirects), and some just result in poor efficiency. However, I would really like to hear the whole scoop on what needs to be done to get it right; up until know I haven't been too concerned becuase our ``gateway'' is the primary machine here, so it doesn't do too much forwarding. It seems to work fine to other unix machines, but the throughput that Symbolics lispmachines see is horrible. Also, how different is the 4.3 implementation? --Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA --bruce@think.com, ihnp4!think!bruce; +1 617 876 1111 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860520173320.6.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986052013330000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@SCRC-QUABBIN.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Port Multiplexing Details Message-ID: <860520173320.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 20-May-86 17:33:00 EDT Article-I.D.: FIREBIRD.860520173320.6.DCP Posted: Tue May 20 17:33:00 1986 Date-Received: Wed, 21-May-86 06:17:22 EDT References: <860519074440.9.MARGULIES@REDWING.SCRC.Symbolics.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa It shouldn't end in CRLF. For that matter, you might as well do what CHAOS did: add arguments to the 'contact name'. You could even use the urgent pointer to delimit the end of the contact/name arguments! In the CHAOS protocol, there is only one type of connection: you connect with a packet that has contact name and arguments. There is no 'datagram equivalent'. I guess I'm not sure what the UDP problem is, possibly because I don't know how UDP connections get started. Isn't there a 'first' packet that can include the contact name? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605202153.AA00080%40apolling.imagen.uucp] <1986052013532300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@imagen.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Fiber-optic Ethernet Extender Message-ID: <8605202153.AA00080@apolling.imagen.uucp> Date: Tue, 20-May-86 17:53:23 EDT Article-I.D.: apolling.8605202153.AA00080 Posted: Tue May 20 17:53:23 1986 Date-Received: Wed, 21-May-86 06:21:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.dec.com Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Sorry that this is a little off the topic, but someone on this list probably knows the answer to this question. We are in need of a way to extend our network across a conduit to an adjacent building. To simplify matters, we'd like to use an "ethernet extender" device that hooks two halves of an ethernet together with a fiber optic cable and looks like a repeater (?). I seem to remember that something like this exists, but I don't remember much about it. Does anyone know about such a product? Does anyone have clever ideas of how to connect two ethernets in different but adjacent buildings (don't bother to tell me about gateways, I know about them). - Geof Cooper Imagen ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12208373228.43.HEDRICK%40RED.RUTGERS.EDU] <1986052021570500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: more oddities from the swamp Message-ID: <12208373228.43.HEDRICK@RED.RUTGERS.EDU> Date: Wed, 21-May-86 01:57:05 EDT Article-I.D.: RED.12208373228.43.HEDRICK Posted: Wed May 21 01:57:05 1986 Date-Received: Thu, 22-May-86 01:23:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 64 Approved: tcp-ip@sri-nic.arpa I have come up with a somewhat better kludge for notifying my hosts about the gateway than using broadcast ICMP redirects. The machines I am worried about are normally configured to run routed as they come out of the box. It turns out that it is possible for a gateway to advertise via routed that network 0 is one of the destinations it can forward to. This will set up the gateway as a default gateway on the routed clients. This seems a more controlled way of doing what I want then unsolicited ICMP redirects, since routed is the protocol that gateways are supposed to use to announce themselves. However there is another interesting problem with either approach. They both require broadcasts, but it is not clear whether it is safe to do broadcasts on our networks. Our problem is that half of our hosts know about subnetting and the other half don't. We have to make our Pyramid and Sun kernels know about subnetting, because we have machines of both kinds with more than one interface. But we have lots of machines from other vendors that do not support subnets and do not supply source. Generally this is not a big deal. They can talk to each other. Routing entries have to be a bit different for the two classes of machines, since one thinks all of 128.6 is one network, whereas the other knows about 128.6.n. But our gateway can handle the ARP hack, so if a non-subnet machine ARPs a machine on a different subnet, the gateway handles it. The problem comes in when we send a broadcast. the only broadcast address that Unix will understand is network.0 (I think this is probably a bug. But it doesn't do me any good to send a broadcast which meets all the RFC's but nobody will receive. So I'm stuck.) The question is, what network number should I use. If I send to 128.6.0.0, the non-subnet machines accept it just fine. But the subnet machines all think I am trying to send a broadcast on subnet 0. Since that is not their subnet, they do not process the broadcast. For some reason that I don't quite understand, we get back a bunch of ICMP ttl exceeded messages. As far as I can tell, some of the machines try to forward the message to subnet zero, and get into a routing loop. If I send to 128.6.4.0, the subnet machines accept it just fine. But the non-subnet machines think I am trying to send to host 4.0 on network 128.6. They helpfullly attempt to forward it. Thus I suddenly get an ARP request from every non-subnet machine, asking for the address of 128.6.4.0. Our Arpanet gateway, which also does not know we have subnets, also thinks we are trying to get it to forward packets to 128.6.4.0. But it notices that this is on the same network, pronouces it an utterly bogus request, and sends back an ICMP redirect to the original sender, saying "do it yourself, idiot" [by the way, is this a standard use of ICMP redirect? What is a gateway supposed to do when a host asks it to forward a packet back onto the same network that it came in from? Intuitively, it seems reasonable that an ICMP redirect should occur, but it is not clear what gateway address one should use. Our Arpanet gateway uses the originator's address. This is somehow morally correct and esthetically satisfying, but no implementation that I know of knows what to do when given an ICMP redirect pointing back at itself.] The net effect of all of this is the any broadcast results in a flurry of other network traffic. This makes it seem unreasonable to use any protocol that requires a broadcast every 30 sec. By the way, this is not the worst symptom of networks containing a mix of subnet and nonsubnet machines. Now and then somebody brings up a Sun kernel that does not have the subnet patches. If you try to boot a diskless Sun on a network containing a mix of subnet and nonsubnet machines, the entire network comes to a halt for a period of a minute or so. (Actually to be fair, the only machines that come to a halt are other Suns and Celerities. Our Pyramids and DEC-20s seem unaffected.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12208388829.19.JNC%40XX.LCS.MIT.EDU] <1986052023224700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNC@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: more oddities from the swamp Message-ID: <12208388829.19.JNC@XX.LCS.MIT.EDU> Date: Wed, 21-May-86 03:22:47 EDT Article-I.D.: XX.12208388829.19.JNC Posted: Wed May 21 03:22:47 1986 Date-Received: Thu, 22-May-86 01:39:27 EDT References: <12208373228.43.HEDRICK@RED.RUTGERS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa Sorry, my bogometer just tripped when I got to the phrase 'routed is the protocol that gateways are supposed to use to announce themselves'. First, this protocol is not documented anywhere. Second, it's not an official Internet protocol. Third, it is a gross violation of IP design philosophy to have hosts know about a gateway routing protocol for any reason, let alone just to find out where gateways are. The Internet Engineering committee has talked about a new ICMP message for hosts to find gateways; I'll try to get this written up soon. I sympathize with your problems with Unix and broadcast addresses. We get shafted by the same thing; the upward compatability with all the nonstandard stuff and gratuitous functionality (such as non-subnet hosts fowarding packets to 128.6.4.0) in 4.2 is an incredible drag. It is to prevent confusion about exactly who is being broadcast to that I maintain that the 'default' broadcast address to use is all 1's, rather than use net.1's or subnet.1's, etc. It's much harder to lose using all 1's; the only possible meaning is 'local wire'. Unfortunately, it's way to late to put the 4.2 genie back in the bottle. Maybe we should all quit and become wood carvers? Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [GZT.TDF.12208407466.BABYL%40MIT-OZ] <1986052101050000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: FTD%MIT-OZ@MC.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Fiber-optic Ethernet Extender Message-ID: Date: Wed, 21-May-86 05:05:00 EDT Article-I.D.: MIT-OZ.GZT.TDF.12208407466.BABYL Posted: Wed May 21 05:05:00 1986 Date-Received: Thu, 22-May-86 01:39:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa Dec makes one but I don't have the part number. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052102150000> Received: from SU-AI.ARPA by SRI-NIC.ARPA with TCP; Wed 21 May 86 13:27:45-PDT Date: 21 May 86 0915 PDT From: Joe Weening Subject: ICMP redirects To: tcp-ip@SRI-NIC.ARPA What do the ICMP redirects that are used to fool Unix contain in the field that is supposed to be the Internet header of the original datagram causing a redirect? Can you just make up some values to cause the action that you desire? It would seem that hosts should do some validity checking on redirects before believing them. This should include checking the Internet header field to see if it corresponds to a packet that was sent out. It would also be useful to see if the gateway sending a redirect is in fact the one to which the original message was sent, and ignore it if not. But this is complicated by the fact that it is apparently legal for a gateway to use any of its addresses as the IP source address of the redirect. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MDC-SRV-9818G%40OFFICE-1] <1986052105200000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: SRV.MDC@OFFICE-1.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Fiber-optic Ethernet Extender Message-ID: Date: Wed, 21-May-86 09:20:00 EDT Article-I.D.: OFFICE-1.MDC-SRV-9818G Posted: Wed May 21 09:20:00 1986 Date-Received: Thu, 22-May-86 02:05:37 EDT References: <8605202153.AA00080@apolling.imagen.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Digital Equipment Company sells two ethernet repeaters. Their local ethernet repeater (DEREP-AA) can connect two 500 meter segments of Baseband Ethernet coax. Their Remote Ethernet Repeater (DEREP-RA) uses a fiber optic cable to connect two segments that are up to 1000 meters apart. I got these out of DEC's Networks and Communications Buyer's Guide. Your local DEC rep should be able to get this for you. I am not affiliated with DEC in any way other than using their products. Stephen Veit (Veit@Office-1) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605221941.AA21542%40ucbvax.Berkeley.EDU] <1986052105432200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: hoffman%pitt@CSNET-RELAY.ARPA (Bob Hoffman) Newsgroups: mod.protocols.tcp-ip Subject: Re: Fiber-optic Ethernet Extender Message-ID: <8605221941.AA21542@ucbvax.Berkeley.EDU> Date: Wed, 21-May-86 09:43:22 EDT Article-I.D.: ucbvax.8605221941.AA21542 Posted: Wed May 21 09:43:22 1986 Date-Received: Fri, 23-May-86 20:22:24 EDT References: <8605202153.AA00080@apolling.imagen.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Fiber optic Ethernet extenders are made by American Photonics, Inc.; 71 Commerce Drive; Brookfield Center, CT 06805; 800-626-5745 or 203-775-8950/8955. Their RL6000 series of Ethernet repeaters will connect two segments of a V2.0 or IEEE 802.3 Ethernet LAN by way of duplex optical fiber cable up to 1000 meters in length. Price is around $4K/pair. I have not used these units, but we are considering their purchase to link up two Ethernets on campus. Another department at Pitt has purchased T1 multiplexers from API and they are satisfied. -- Bob Hoffman, N3CVL {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman Pitt Computer Science hoffman%pitt@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052105432201> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Thu 22 May 86 09:27:33-PDT Received: from pitt by csnet-relay.csnet id aa00709; 22 May 86 9:31 EDT Received: by pitt (4.12/4.7) id AA28943; Wed, 21 May 86 09:43:22 edt Date: Wed, 21 May 86 09:43:22 edt From: Bob Hoffman To: tcp-ip@SRI-NIC.ARPA Subject: Re: Fiber-optic Ethernet Extender In-Reply-To: <8605202153.AA00080@apolling.imagen.uucp> Fiber optic Ethernet extenders are made by American Photonics, Inc.; 71 Commerce Drive; Brookfield Center, CT 06805; 800-626-5745 or 203-775-8950/8955. Their RL6000 series of Ethernet repeaters will connect two segments of a V2.0 or IEEE 802.3 Ethernet LAN by way of duplex optical fiber cable up to 1000 meters in length. Price is around $4K/pair. I have not used these units, but we are considering their purchase to link up two Ethernets on campus. Another department at Pitt has purchased T1 multiplexers from API and they are satisfied. -- Bob Hoffman, N3CVL {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman Pitt Computer Science hoffman%pitt@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860521151644.774883%40MIT-MULTICS.ARPA] <1986052107160000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Multiplexing Details Message-ID: <860521151644.774883@MIT-MULTICS.ARPA> Date: Wed, 21-May-86 11:16:00 EDT Article-I.D.: MIT-MULT.860521151644.774883 Posted: Wed May 21 11:16:00 1986 Date-Received: Thu, 22-May-86 06:19:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 122 Approved: tcp-ip@sri-nic.arpa Are the general readership really interested in seeing this design discussion continue on the TCP-IP list? I haven't received any complaints about my long messages, but perhaps the interested parties have already identified themselves. If this goes on much longer, should we create a new list or something? Putting the contact name in a TCP option in the header of the SYN packet is cute: it solves the problem of gateways finding out what service owns the connection. It is ugly to have to use a reserved port number as well, but it would clearly be necessary so that hosts which didn't implement the protocol would properly reject such packets. However, putting the contact name in the header imposes length limitations much more stringent than placing it in the data stream. It also requires significant changes to all TCPs that participate in this game. Perhaps that seems desirable to others, but I view both as disasterous. A 32 character name length may seem adequate, but it really isn't. First, the number czar may give out long suffixes, like SYMBOLICS-, THINKING-MACHINES-, HONEYWELL-INFORMATION-SYSTEMS-, and so on. Within an organization, there may be further delegation, like OFFICE-SYSTEMS-, ULTRIX-, SCRC-, and so on. It would be better to spell out names like MANDELBROT, rather than having them compressed into MNDLBRT or given less clear names like DCP3. In the connection model we are currently using, there is no use for contact arguments. There is no pressing need to implement them, since we are using a stream protocol. The contact arguments can effectively just appear in the TCP data stream. I believe that FINGER is a good example. For TCP, the FINGER server arguments appear at the beginning of the data stream. In fact, they are the whole data stream in one direction. In CHAOS, the first packet contains the FINGER contact name and the arguments. The only other packets to go in that direction are the acknowledgements of the reply. TCPs generally assume a zero window until the connection is established, so TCP requires at least two packets to do what CHAOS does in one. However, contact arguments can server as protocol specific options, and it is easy to envision services that might be offered for more than one stream protocol. For example, a system might support TCP, DECNET (whatever their stream protocol is), CHAOS, TP4, X.25, and so on. Defining an out-of-band mechanism for later use preserves flexibility. Even though it makes life harder for security-minded gateways, I think that the advantages of putting the contact information at the front of the stream outweigh it. Protocols which must cross the secure gateways can be assigned numbers. The gateways can reject multiplexor port SYN packets. Sending the contact information urgently is less disruptive since many TCPs wouldn't have to be modified to permit this. The advantage of a protocol that sends the contact information in the stream is that no underlying mechanisms need be modified on either side of the connection. The user side just sends the contact information at the beginning of the stream, suitably delimited, and the server side reads it and acts on it. The server TCP doesn't need to be modified; the server could make a new connection to a numbered port and transfer bytes between the two connections transparently. Still, there may be TCPs that don't handle urgent data well. The rationale for using a network newline (CRLF) to delimit the connection name is that this is a standard delimiter sequence which is widely understood across the network. Any ASCII character may be sent without triggering recognition of this delimiter since a CRLF can be quoted as CR NUL LF. (That is asking for trouble since there are implementations which are defective in this department.) Certainly any printing character can be sent with any implementation. Sending the contact name, an optional space followed by contact arguments, and ending the whole thing with a newline makes it very easy for both user and server. The server can read one line from the TCP, which is often available as a primitive. (If it isn't, there are other ways of ensuring that too much data is not read from the TCP, like reading one character at a time.) On Multics, either urgent or newline-delimited contact names would be easy to implement. Interoperability would be possible in a very short time, although improvements could be made later. A new option would require significant changes to the underlying TCP for every system that used it, a much bigger job. UDP is a connectionless protocol. It has no options, and no memory from one packet to the next. Requests are sent out to a well known port from a local port which is used to identify the reply, if any. There are two common scenarios which UDP is used for: a simple announcement or query where each participating host sends at most one packet, and as an underlying base for implementing some complex protocol. To ask the time, for example, one host sends a UDP packet to the time port; there may be no data in the packet (except the port number to return the time to, which is part of the UDP header). The reply contains only the time, perhaps as a 32 bit number. When it arrives, the transaction is finished. This might be a good candidate for a UDP-2 protocol which carried the name "TIME-IN-SECONDS-SINCE-1970/01/01-00:00:00-GMT" rather than a well known port number. At least one such protocol would get the short name "TIME", I suppose, since the desire for precise names doesn't seem to be widespread. Other examples include TFTP and the remote virtual disk protocol. Both of these applications maintain considerable state information about a session and exchange many packets during the session. Using UDP-2 would increase the overhead of the protocols, and might decrease the amount of useful data sent in a datagram. For these sorts of services, some other service to translate service names into port numbers would be much more efficient. The UDP lookup server, like Benson's version of the multiplexor server, is easy to implement. UDP-2 might be nice, but is an even bigger job than adding a new TCP option, and I never expect to see it in general use. Concerning contact names: how about reserving some TCP options as "higher-level protocol specific"? The options could vary in meaning and even length depending on which protocol (well known port) was used. They would be valid only for the SYN packet. TCPs which play this game could indicate in the LISTEN or OPEN call that they would accept such options, and define a way for the application server to read them when the connection is established. TCPs which don't implement the options, or TCBs which don't accept the options would cause the connection to be aborted rather than established. This precursor would make it possible to implement St. Johns' version of the Named-Service server, and would provide a mechanism like contact arguments. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605220118.AA06317@ucbvax.Berkeley.EDU] <1986052108150000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JJW@SU-AI.ARPA (Joe Weening) Newsgroups: mod.protocols.tcp-ip Subject: ICMP redirects Message-ID: <8605220118.AA06317@ucbvax.Berkeley.EDU> Date: Wed, 21-May-86 12:15:00 EDT Article-I.D.: ucbvax.8605220118.AA06317 Posted: Wed May 21 12:15:00 1986 Date-Received: Thu, 22-May-86 06:27:18 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa What do the ICMP redirects that are used to fool Unix contain in the field that is supposed to be the Internet header of the original datagram causing a redirect? Can you just make up some values to cause the action that you desire? It would seem that hosts should do some validity checking on redirects before believing them. This should include checking the Internet header field to see if it corresponds to a packet that was sent out. It would also be useful to see if the gateway sending a redirect is in fact the one to which the original message was sent, and ignore it if not. But this is complicated by the fact that it is apparently legal for a gateway to use any of its addresses as the IP source address of the redirect. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605211759.AA00037%40apolling.imagen.uucp] <1986052109593600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: geof@imagen.UUCP (Geof Cooper) Newsgroups: mod.protocols.tcp-ip Subject: Re: Fiber-optic Ethernet Extender Message-ID: <8605211759.AA00037@apolling.imagen.uucp> Date: Wed, 21-May-86 13:59:36 EDT Article-I.D.: apolling.8605211759.AA00037 Posted: Wed May 21 13:59:36 1986 Date-Received: Thu, 22-May-86 06:33:01 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.dec.com Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa Much thanks for the 15 or so immediate responses. To summarize, people have mentioned that repeaters and half-repeaters (sometimes called "remote repeaters) are available as products from DEC, Xerox, Ungerman Bass, American Photonics (actually, this last one is a fiber extension of the Ethernet transceiver cable (between the tap and the host)). One idea suggested was to run low-cost ethernet coax between buildings, with a half repeater on each side of it. DEC's products were by far the most frequently mentioned. Several people said they have one or the other product installed and working. There were two products mentioned. One was the DEREP repeater, which is "intended for exactly the type of use you describe (to link buildings where there may be a ground potential difference, perhaps a small conduit, and a moderate distance (I forget the max, but it is something like 1000M I think))" [JSPEAR@AI.AI.MIT.EDU]. The other was the Lanbridge-100, which seems to be something more like a "transparent gateway" -- it peeks at network traffic and selectively relays information. It apparently has a fiber optical extension available as an option. The DEREP-RA Remote Ethernet Repeater cost $4,400 (for both halves) in September '85. However, "it seems to be slightly divergent from the Ethernet specs in that it only seems to work properly when connected to the coax with a DEC transceiver (H-4000). Aside from that problem, we've had one in use...without troubles [mckenzie@j.bbn.com]. Thanks again, - Geof Cooper Imagen ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12208515943.62.HEDRICK%40RED.RUTGERS.EDU] <1986052111010200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: Re: more oddities from the swamp Message-ID: <12208515943.62.HEDRICK@RED.RUTGERS.EDU> Date: Wed, 21-May-86 15:01:02 EDT Article-I.D.: RED.12208515943.62.HEDRICK Posted: Wed May 21 15:01:02 1986 Date-Received: Thu, 22-May-86 06:24:12 EDT References: <12208388829.19.JNC@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@sri-nic.arpa I have been through this with Mills also. Everything that you say is right. But it is also nearly irrelevant for those of us out in the swamp surrounded by binary-only alligators. I would be quite happy with an ICMP who is my gateway or ICMP I am the default gateway. But until such a thing shows up, I use what I have, and that is routed. I think this list needs to discuss both what the standards should be and what we should do until it becomes practical to use the standards. My best estimate is that it will take about 3 years between the time you define something and when we can depend upon using it. At the moment it is likely to take longer than 3 years, since anything that is done now will have just missed a new release of Berkeley Unix. A number of vendors don't do anything until a features shows up in BSD. So any new ICMP things are likely to have to wait for 4.4, then another year or so until all the vendors incorporate the 4.4 features. Lest you think I am being overly pessimistic, look at the slow spead of subnets. A change in broadcast address is going to be particularly messy, since unless everybody does it at the same time (a manifest impossibility), we could be in for some incompatibility. I would recommend that implementations should be prepared to accept any of net.0 net.subnet.0 -1 for the moment. Once everyone recognizes -1, all senders would start using it, and the 0's could be phased out. Alternatively, your subnet RFC could have specified that the correct broadcast address for implementations that use 0's is net.0, not net.subnet.0. then we would have one less incompatibility to deal with. By the way, a month or so ago we got this shiny new collection of Internet protocol documents. I assume this is what most vendors use to do their implementations. I didn't see subnetting it in. I didn't see any signs of -1 being specified as the broadcast address. How many vendors do you think know that they are supposed to be changing the broadcast address? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052112413600> Received: from andrew.cmu.edu by SRI-NIC.ARPA with TCP; Wed 21 May 86 14:44:33-PDT Received: by andrew.cmu.edu (4.12/3.15) id ; Wed, 21 May 86 17:43:29 edt Received: FROM leong VIA queuemail ID ; Wed, 21 May 86 17:42:11 EDT Date: Wed, 21 May 86 17:41:36 EST From: John Leong Subject: Re: Fiber-optic Ethernet Extender To: imagen!geof@decwrl.DEC.COM (Geof Cooper) Cc: tcp-ip@sri-nic.arpa DEC, Ungermann-Bass (UB) and American Photonics (API) make both local and remote repeaters. All the remote repeaters use fibre optic cables. DEC and UB requires 100 micron cable while API is engineered for 50 micron. (Phone companies had been busy putting in 50 micron cables. They are now changing to 62.5). One thing you should know is that when you connect a 100 micron light source into a 50 micron cable, you lose 75% of your light !!! API has an Ethernet extender which is really a long fibre drop cable transceiver and is quite cute. If you want to join two nets together but do not want to sum up the traffic, you can investigate into the LANbridge from DEC. They sell both a local as well as a remote version (or you can use a local version with the API Ethernet extender). I really like the LANbridge better than plain repeater since they will relay only applicable packets to the other side. However, they do cost $$$$. (roughly $8,000 list) John Leong ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605212236.AA01756%40monk.PROTEON.COM] <1986052114365600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mar@MONK.PROTEON.COM (Mark A. Rosenstein) Newsgroups: mod.protocols.tcp-ip Subject: more oddities from the swamp Message-ID: <8605212236.AA01756@monk.PROTEON.COM> Date: Wed, 21-May-86 18:36:56 EDT Article-I.D.: monk.8605212236.AA01756 Posted: Wed May 21 18:36:56 1986 Date-Received: Fri, 23-May-86 20:19:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa There is something that can be done to cut down on the flurry of packets in response to a broadcast. On all of the 4.2 Unix machines which are not serving as gateways, turn off IP forwarding in the kernel. This will cause them to no longer send ICMP messages or forward packets that were not specifically addressed to them in the first place. Forwarding is controlled by the variable _ipforwarding. If this is set to zero, these extra packets will not be generated. On binary-only systems, you still can turn it off using adb on /vmunix. -Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605220232.AA07216%40ucbvax.Berkeley.EDU] <1986052114413600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong@PO1.ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: Re: Fiber-optic Ethernet Extender Message-ID: <8605220232.AA07216@ucbvax.Berkeley.EDU> Date: Wed, 21-May-86 18:41:36 EDT Article-I.D.: ucbvax.8605220232.AA07216 Posted: Wed May 21 18:41:36 1986 Date-Received: Thu, 22-May-86 06:28:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa DEC, Ungermann-Bass (UB) and American Photonics (API) make both local and remote repeaters. All the remote repeaters use fibre optic cables. DEC and UB requires 100 micron cable while API is engineered for 50 micron. (Phone companies had been busy putting in 50 micron cables. They are now changing to 62.5). One thing you should know is that when you connect a 100 micron light source into a 50 micron cable, you lose 75% of your light !!! API has an Ethernet extender which is really a long fibre drop cable transceiver and is quite cute. If you want to join two nets together but do not want to sum up the traffic, you can investigate into the LANbridge from DEC. They sell both a local as well as a remote version (or you can use a local version with the API Ethernet extender). I really like the LANbridge better than plain repeater since they will relay only applicable packets to the other side. However, they do cost $$$$. (roughly $8,000 list) John Leong ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12208583850.28.JNC%40XX.LCS.MIT.EDU] <1986052117140400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: more oddities from the swamp Message-ID: <12208583850.28.JNC@XX.LCS.MIT.EDU> Date: Wed, 21-May-86 21:14:04 EDT Article-I.D.: XX.12208583850.28.JNC Posted: Wed May 21 21:14:04 1986 Date-Received: Fri, 23-May-86 02:09:37 EDT References: <12208515943.62.HEDRICK@RED.RUTGERS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa The reason the subnet RFC didn't speak about net.0 versus net.subnet.0 is a) we wanted net.broadcast to mean something different from net.subnet.broadcast, and b) that spec was written, although unfortunately not released, before 4.2 came out. I have already complained fairly strongly to Jon Postel about the lack of subnet stuff in the IP protocol documents. I didn't realize that broadcast was also missing. The whole problem of out of date implementations attached to the network system is one of the key organizational (as opposed to technical) problems the system faces right now. You are correct that currently the time around the loop is several years. The problem is that this kind of delay is not acceptable if the system is going to continue to grow successfully at the rate that it has been growing. Things are going to break and need to be replaced, and we can't wait around for years until vendors feel like fixing things. I think we need two things: a certification process, and pressure from buyers. The need for the first is clear; right now there is no comprehensive test of whether or not something correctly obeys all the protocols. It's hard to beat up vendors when you don't have a definite measuring stick for them. Second, people have to get militant about timely support. Don't buy something if you don't get either a) source, or b) a written commitment to pass the testing suite within N months of changes. Such products may cost more, but look at the other side: you will waste countelss skilled people hours pasting things together if you buy whatever's cheapest. But people *have* to exercise discipline and say to vendors "No, your stuff does not meet the spec, *go away*". Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605220813.AA13263%40brillig.umd.edu] <1986052200134300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: chris@BRILLIG.UMD.EDU (Chris Torek) Newsgroups: mod.protocols.tcp-ip Subject: 4.3(beta) subnets & routed Message-ID: <8605220813.AA13263@brillig.umd.edu> Date: Thu, 22-May-86 04:13:43 EDT Article-I.D.: brillig.8605220813.AA13263 Posted: Thu May 22 04:13:43 1986 Date-Received: Fri, 23-May-86 02:45:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa This is perhaps obvious in retrospect, but it is a bad idea to run routed between two machines with different subnet masks. Boy do they get confused. Sorry about all those UMDNET packets that sprayed out into the MILNET (though that may have been due to an unrelated mistake). (We just turned on subnets, and I did it in phases. That was a mistake. Do it all at once!) Other than that, hey!, it works very well indeed. You will need to use `route -n add ' (note the `-n') if your subnet gateways do not run routed. I am not sure what happens if they do: ours are not under my control (for which many are no doubt grateful :-) ). Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605221146.AA28463%40seismo.CSS.GOV] <1986052203464600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mo@SEISMO.CSS.GOV (Mike O'Dell) Newsgroups: mod.protocols.tcp-ip Subject: multiplexing Message-ID: <8605221146.AA28463@seismo.CSS.GOV> Date: Thu, 22-May-86 07:46:46 EDT Article-I.D.: seismo.8605221146.AA28463 Posted: Thu May 22 07:46:46 1986 Date-Received: Fri, 23-May-86 20:17:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa I don't know which is funnier: seeing this august community very nearly advocating the need for what is almost the ISO session protocol, or seeing it retrench and reinvent the "USER DATA" part of the X.25L3 "Call Request" packet as an alternative. (Even the X.25 boys now believe in the folly of the latter.) Jeez! Could the the ISOOSI Tribe bit mongers have been right????? Ducking under the table for a while until everyone settles down, -Mike O'Dell -------- "Little Packets, Little Packets, Little Packets made of Ticky Tacky, ..... Little Packets just the same." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605231459.AA05939%40ucbvax.Berkeley.EDU] <1986052204142600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: louden@MITRE-GATEWAY.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: more oddities from the swamp Message-ID: <8605231459.AA05939@ucbvax.Berkeley.EDU> Date: Thu, 22-May-86 08:14:26 EDT Article-I.D.: ucbvax.8605231459.AA05939 Posted: Thu May 22 08:14:26 1986 Date-Received: Sat, 24-May-86 01:02:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa The "shiny new collection of Internet protocol documents" does have the "-1" address. See volume 3 page 177 last paragraph. It does not say "-1" because that makes assumptions about your hardware it is described as 'addresses of all ones are to be interpreted as meaning "all"'. The word broadcast is also not used because it makes assumptions about your hardware. Subnets are mentioned in volume 3 page 244 but I did not see any detailed discussion. The documents make an excelent starting point but may not be complete for all applications. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052204142601> Received: from mitre-gateway.arpa by SRI-NIC.ARPA with TCP; Fri 23 May 86 07:17:47-PDT Date: 22 May 1986 8:14:26 EDT (Thursday) From: T. Michael Louden (MS W422) Subject: Re: more oddities from the swamp In-Reply-to: Your message of 21 May 86 15:01:02 EDT To: hedrick@rutgers Cc: tcp-ip@sri-nic, louden@mitre-gateway.arpa The "shiny new collection of Internet protocol documents" does have the "-1" address. See volume 3 page 177 last paragraph. It does not say "-1" because that makes assumptions about your hardware it is described as 'addresses of all ones are to be interpreted as meaning "all"'. The word broadcast is also not used because it makes assumptions about your hardware. Subnets are mentioned in volume 3 page 244 but I did not see any detailed discussion. The documents make an excelent starting point but may not be complete for all applications. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605221427.AA10440%40Godot.Think.Com] <1986052206274200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: 4.2bsd gateways Message-ID: <8605221427.AA10440@Godot.Think.Com> Date: Thu, 22-May-86 10:27:42 EDT Article-I.D.: Godot.8605221427.AA10440 Posted: Thu May 22 10:27:42 1986 Date-Received: Fri, 23-May-86 20:11:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa In response to the message sent Tue, 20 May 86 15:33:51 edt from bruce@Think.Com Bruce, Rather than trying to figure out what needs to be done to upgrade 4.2bsd to an honest gateway, why not start with the requirements for such a beast and work backwards? See RFC-985 for a first step in such a process. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052209160000> Received: from LOGICON.ARPA by SRI-NIC.ARPA with TCP; Thu 22 May 86 16:21:47-PDT Date: 22 May 86 16:16 PDT From: Tom Perrine To: tcp-ip@sri-nic Cc: Perrine@logicon Subject: The Big Bug? This is really a dumb question, prompted by the recent comment about using ICMP redirects to tell local hosts where to send things... I get the impression that most (or at least, some) TCP/IP implementations will accept a redirect from anyone. Is this true? If so... What is to stop me (or Kevensky Gregory Breznhev) from sending a redirect to every host on my net, i.e. MILNET, indicating (for example) that they should send all of their ARPA traffic to me? My host could then copy all of the packets and forward them to the proper gateway. Talk about Big Brother, not to mention the performance impact! I am sure that I am missing something, this couldn't be true! Tom ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052212310000> Received: from LLL-MFE.ARPA by SRI-NIC.ARPA with TCP; Thu 22 May 86 20:03:02-PDT Date: Thu, 22 May 86 19:31 PDT From: Provan@LLL-MFE.ARPA Subject: re: the big bug? To: Tcp-ip@nic.arpa what a happy coincident: i was just about to ask tcp-ip about this very point when the subject suddenly popped up for me! some implementations, the one i'm sending this from in fact, only apply redirects to the particular connection they apply to. for example, a redirect for a host with multiple connections from here will not cause any of the connections to change their route except the one that actually sent the redirect packet. on the other hand, i suspect there are sites that you could restrict arpanet access for by sending a redirect and then not even bothering to forward the packets. it would probably take human intervention in soem cases to get the routing entry out of the tables. CC: Perrine@LOGICON.ARPA, Tcp-ip@nic.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605230038.AA26516%40ucbvax.Berkeley.EDU] <1986052215160000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Perrine@LOGICON.ARPA (Tom Perrine) Newsgroups: mod.protocols.tcp-ip Subject: The Big Bug? Message-ID: <8605230038.AA26516@ucbvax.Berkeley.EDU> Date: Thu, 22-May-86 19:16:00 EDT Article-I.D.: ucbvax.8605230038.AA26516 Posted: Thu May 22 19:16:00 1986 Date-Received: Sat, 24-May-86 05:39:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa This is really a dumb question, prompted by the recent comment about using ICMP redirects to tell local hosts where to send things... I get the impression that most (or at least, some) TCP/IP implementations will accept a redirect from anyone. Is this true? If so... What is to stop me (or Kevensky Gregory Breznhev) from sending a redirect to every host on my net, i.e. MILNET, indicating (for example) that they should send all of their ARPA traffic to me? My host could then copy all of the packets and forward them to the proper gateway. Talk about Big Brother, not to mention the performance impact! I am sure that I am missing something, this couldn't be true! Tom ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605230325.AA29122%40ucbvax.Berkeley.EDU] <1986052218310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Provan@LLL-MFE.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: the big bug? Message-ID: <8605230325.AA29122@ucbvax.Berkeley.EDU> Date: Thu, 22-May-86 22:31:00 EDT Article-I.D.: ucbvax.8605230325.AA29122 Posted: Thu May 22 22:31:00 1986 Date-Received: Sat, 24-May-86 05:40:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa what a happy coincident: i was just about to ask tcp-ip about this very point when the subject suddenly popped up for me! some implementations, the one i'm sending this from in fact, only apply redirects to the particular connection they apply to. for example, a redirect for a host with multiple connections from here will not cause any of the connections to change their route except the one that actually sent the redirect packet. on the other hand, i suspect there are sites that you could restrict arpanet access for by sending a redirect and then not even bothering to forward the packets. it would probably take human intervention in soem cases to get the routing entry out of the tables. CC: Perrine@LOGICON.ARPA, Tcp-ip@nic.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605230415.AA19175%40nrl-css.ARPA] <1986052220150000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: dardy@NRL-CSS.ARPA (Hank Dardy) Newsgroups: mod.protocols.tcp-ip Subject: Re: Fiber-optic Ethernet Extender Message-ID: <8605230415.AA19175@nrl-css.ARPA> Date: Fri, 23-May-86 00:15:00 EDT Article-I.D.: nrl-css.8605230415.AA19175 Posted: Fri May 23 00:15:00 1986 Date-Received: Sat, 24-May-86 00:30:20 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa We have been using the Digital DEREP fiber repeaters for close to two years without problem. The fiber has withstood both nature and man made electrical surge (we have a plasma physics group next door). Our installation has over 120 machines connected thru a "virtual" ethernet composed of broadband, baseband and fiber. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605230539.AA00758%40ucbvax.Berkeley.EDU] <1986052220374300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jdreyer@BBNCCV.ARPA (Jonathan Dreyer) Newsgroups: mod.protocols.tcp-ip Subject: Re: The Big Bug? Message-ID: <8605230539.AA00758@ucbvax.Berkeley.EDU> Date: Fri, 23-May-86 00:37:43 EDT Article-I.D.: ucbvax.8605230539.AA00758 Posted: Fri May 23 00:37:43 1986 Date-Received: Sat, 24-May-86 00:30:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa I got good news or bad news, depending on the answer to this question: What do hosts do when they are redirected via a "gateway" that is not on their directly-connected net? If hosts do the right thing, then most redirect pranksters won't get very far. In fact, it is hard to imagine what hosts could reasonably do besides to ignore these bogograms (and maybe complain). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052220374301> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Thu 22 May 86 21:44:26-PDT To: tcp-ip@sri-nic.ARPA cc: jdreyer@BBNCCV.ARPA Subject: Re: The Big Bug? In-reply-to: Your message of 22 May 86 16:16 PDT. Date: 23 May 86 00:37:43 EDT (Fri) From: Jonathan Dreyer I got good news or bad news, depending on the answer to this question: What do hosts do when they are redirected via a "gateway" that is not on their directly-connected net? If hosts do the right thing, then most redirect pranksters won't get very far. In fact, it is hard to imagine what hosts could reasonably do besides to ignore these bogograms (and maybe complain). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052301080000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Fri 23 May 86 09:20:47-PDT Date: 23 May 86 09:08:00 PST From: Subject: IF-11Q/1822 for uVAXen To: "tcp-ip" Reply-To: Those of you who have a need for supporting the 1822 protocol for the uVAX, and have access to a LH-DH driver, can modify that driver to work with the IF-11Q/1822. The differences between the two require driver changes in the way the system communicates with the Control Status Registers. Those changes have been documented by Test personnel here at ACC and are available. For reference the interface requires two dual slots in the backplane and will support either a Distant Host or Local Host connection to the PSN. Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605231624.AA07571%40ucbvax.Berkeley.EDU] <1986052307000500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MILLS@USC-ISID.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: The Big Bug? Message-ID: <8605231624.AA07571@ucbvax.Berkeley.EDU> Date: Fri, 23-May-86 11:00:05 EDT Article-I.D.: ucbvax.8605231624.AA07571 Posted: Fri May 23 11:00:05 1986 Date-Received: Sat, 24-May-86 01:04:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa In response to the message sent 22 May 86 16:16 PDT from Perrine@LOGICON.ARPA Tom, The ICMP redirect includes a copy of the IP header (plus a few bits) of the IPgram that was received and forwarded at the gateway. Presumably, the host receiving such a thing has the opportunity to determine its authenticity using this information. Granted this doesn't nab all the bogs, especially with raw-datagram protocols, but it is much better than nothing at all. What this means is that it's hard to send gratuitous redirects to reasonable implementations that remember, at least for a little while, the address/route bindings recently used. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052307000501> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Fri 23 May 86 08:29:54-PDT Date: 23 May 1986 11:00:05 EDT From: MILLS@USC-ISID.ARPA Subject: Re: The Big Bug? To: Perrine@LOGICON.ARPA, tcp-ip@SRI-NIC.ARPA cc: MILLS@USC-ISID.ARPA In response to the message sent 22 May 86 16:16 PDT from Perrine@LOGICON.ARPA Tom, The ICMP redirect includes a copy of the IP header (plus a few bits) of the IPgram that was received and forwarded at the gateway. Presumably, the host receiving such a thing has the opportunity to determine its authenticity using this information. Granted this doesn't nab all the bogs, especially with raw-datagram protocols, but it is much better than nothing at all. What this means is that it's hard to send gratuitous redirects to reasonable implementations that remember, at least for a little while, the address/route bindings recently used. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605231814.AA09251%40ucbvax.Berkeley.EDU] <1986052309080000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gary@ACC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: IF-11Q/1822 for uVAXen Message-ID: <8605231814.AA09251@ucbvax.Berkeley.EDU> Date: Fri, 23-May-86 13:08:00 EDT Article-I.D.: ucbvax.8605231814.AA09251 Posted: Fri May 23 13:08:00 1986 Date-Received: Sat, 24-May-86 01:24:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Those of you who have a need for supporting the 1822 protocol for the uVAX, and have access to a LH-DH driver, can modify that driver to work with the IF-11Q/1822. The differences between the two require driver changes in the way the system communicates with the Control Status Registers. Those changes have been documented by Test personnel here at ACC and are available. For reference the interface requires two dual slots in the backplane and will support either a Distant Host or Local Host connection to the PSN. Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605231710.AA22915%40sri-spam.arpa] <1986052309103400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gds@SRI-SPAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: The Big Bug? Message-ID: <8605231710.AA22915@sri-spam.arpa> Date: Fri, 23-May-86 13:10:34 EDT Article-I.D.: sri-spam.8605231710.AA22915 Posted: Fri May 23 13:10:34 1986 Date-Received: Sat, 24-May-86 19:30:04 EDT References: <8605230539.AA00758@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa > What do hosts do when they are redirected via a "gateway" that is not > on their directly-connected net? 4.2 hosts running BBN TCP/IP ignore redirects from gateways which are not on their directly attached net. In addition, there is a notion of the "connected set of gateways" which are allowed to send redirects to the host. It starts with the "default" gateway, installed by the system manager. The default gateway may redirect the host to another gateway if there is a better route, and any other gateways put in the routing tables from similar redirects may do likewise. A gateway which has not been "installed" from previous redirects cannot redirect the host -- in fact the code is commented "Who are you, and why are you talking to us, and how do we know the IP source is not a lie?" --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860523194159.109010%40MIT-MULTICS.ARPA] <1986052311410000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Postmaster Alert -- CISL-SERVICE-MULTICS.ARPA => MIT-MULTICS.ARPA Message-ID: <860523194159.109010@MIT-MULTICS.ARPA> Date: Fri, 23-May-86 15:41:00 EDT Article-I.D.: MIT-MULT.860523194159.109010 Posted: Fri May 23 15:41:00 1986 Date-Received: Sat, 24-May-86 19:49:23 EDT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 38 Approved: tcp-ip@sri-nic.arpa Yesterday, 22 May 1986, CISL-SERVICE-MULTICS.ARPA (10.3.0.31) went off the air. The Cambridge Information Systems Lab closed its doors today. At some future time, probably in about 2 months, a new Multics will come on the ARPAnet at a different Honeywell location in Billerica, MA. The name and address are not definitely known at this time. For the moment, all mail intended for recipients at CISL-SEREVICE-MULTICS.ARPA should be sent to MIT-MULTICS.ARPA (10.0.0.6) instead. This includes mail destined for other non-Internet sites which uses CISL-DEVELOPMENT-MULTICS.ARPA as a gateway. For example, Multics users in Phoenix, AZ, receive mail as User%PCO-MULTICS@CISL-DEVELOPMENT-MULTICS.ARPA. To the best of our ability, all mail will be delivered by MIT-Multics to the same parties as CISL-Service-Multics would have. It is possible that for the first few days some mail might be rejected, but it will not be delivered to the wrong person. The host table from SRI-NIC and the ARPA domain servers will be updated soon to show all the names of CISL-SERVICE-MULTICS.ARPA as addnames on MIT-MULTICS.ARPA. However, this may not be accomplished until next week some time, and that host table may take several days to be picked up by the various hosts, so mail addressed to CISL-SERVICE-MULTICS will be returned by mailers as undeliverable. We apologize for the inconvenience. If your host is known by you to handle significant volume mail to CISL, please consider manually updating your host table or patching your mailer queues. Otherwise, when asked what to do about returned mail, either advise your users of the change or ask them to resend it after the domain server or local host table have been updated. We are concerned that subscribers not be dropped from digests because of an essentially temporary outage. Please feel free to forward this message to any other mailing lists or parties who might be affected. -- Spencer Love for Liaison@MIT-MULTICS.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052403473000> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Sat 24 May 86 04:48:06-PDT Received: by cu-arpa.cs.cornell.edu (5.31/4.30) id AA15810; Sat, 24 May 86 07:47:33 EDT Date: Sat, 24 May 86 07:47:30 EDT From: swb@tcgould.tn.cornell.edu (Scott Brim) Message-Id: <8605241147.AA01896@tcgould.tn.cornell.edu> Received: by tcgould.tn.cornell.edu (5.9/4.30) id AA01896; Sat, 24 May 86 07:47:30 EDT To: leong@andrew.cmu.edu Subject: Re: Fiber-optic Ethernet Extender Cc: tcp-ip@sri-nic.arpa John: American Photonics told me they could handle 50, 62.5 or 100 micron fiber -- and indeed sold me some RL5002s for 62.5 micron. Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- [547309665.1848819027%40XV.MIT.EDU] <1986052410383800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcp-ip-RELAY@SRI-NIC.ARPA, Newsgroups: mod.protocols.tcp-ip Subject: Re: Fiber-optic Ethernet Extender, Re: Fiber-optic Ethernet Extender Message-ID: <547309665.1848819027@XV.MIT.EDU> Date: Sat, 24-May-86 14:38:38 EDT Article-I.D.: XV.547309665.1848819027 Posted: Sat May 24 14:38:38 1986 Date-Received: Sun, 25-May-86 10:48:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa John: American Photonics told me they could handle 50, 62.5 or 100 micron fiber -- and indeed sold me some RL5002s for 62.5 micron. Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052609440000> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Mon 26 May 86 12:19:05-PDT Received: from (1017263)MCMASTER.BITNET by WISCVM.WISC.EDU on 05/26/86 at 12:44:43 CDT Date: 26 MAY 86 13:44-EDT From: 1017263%MCMASTER.BITNET@WISCVM.WISC.EDU To: TCP-IP@SRI-NIC.ARPA Subject: A non-routing problem. Here is a problem from the world of TCP/IP. Why does the Vax retransmit a packet which has been acknowledged ? Also if the PC does window shrinking and the window size becomes zero at the point of transmitting the character, the retry time can be about 30 seconds. The following is a true log of packets between the Vax and the PC. Only the names have been changed to protect my innocence. From PC From Unix/Vax (Using BWTEL) Characters = 82 Seq # = 207 Ack # = 32 Characters = 0 Seq # = 32 Ack # = 289 Characters = 82 Seq # = 289 Ack # = 32 *** Character transmitted before last packet processed Characters = 1 Seq # = 32 Ack # = 289 Characters = 0 Seq # = 371 Ack # = 33 This packet is in response to second to last packet, last packet not yet processed. Characters = 1 same character as above Seq # = 32 Ack # = 371 Characters = 0 Seq # = 371 Ack # = 33 Characters = 82 *** Seq # = 289 Ack # = 33 *** Why Does the Vax retransmit ???? *** Characters = 0 Seq # = 33 Ack # = 371 Characters = 82 Seq # = 371 Ack # = 33 Characters = 0 Seq # = 33 Ack # = 453 - Carl Beame 1017263@MCMASTER.BITNET or BEAME@MCMASTER.BITNET P.S> Any comments or explanations are very welcome. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605262015.AA25680%40ucbvax.Berkeley.EDU] <1986052612180400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: 1017263@MCMASTER.BITNET Newsgroups: mod.protocols.tcp-ip Subject: A non-routing problem. Message-ID: <8605262015.AA25680@ucbvax.Berkeley.EDU> Date: Mon, 26-May-86 16:18:04 EDT Article-I.D.: ucbvax.8605262015.AA25680 Posted: Mon May 26 16:18:04 1986 Date-Received: Tue, 27-May-86 07:13:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 63 Approved: tcp-ip@sri-nic.arpa Here is a problem from the world of TCP/IP. Why does the Vax retransmit a packet which has been acknowledged ? Also if the PC does window shrinking and the window size becomes zero at the point of transmitting the character, the retry time can be about 30 seconds. The following is a true log of packets between the Vax and the PC. Only the names have been changed to protect my innocence. From PC From Unix/Vax (Using BWTEL) Characters = 82 Seq # = 207 Ack # = 32 Characters = 0 Seq # = 32 Ack # = 289 Characters = 82 Seq # = 289 Ack # = 32 *** Character transmitted before last packet processed Characters = 1 Seq # = 32 Ack # = 289 Characters = 0 Seq # = 371 Ack # = 33 This packet is in response to second to last packet, last packet not yet processed. Characters = 1 same character as above Seq # = 32 Ack # = 371 Characters = 0 Seq # = 371 Ack # = 33 Characters = 82 *** Seq # = 289 Ack # = 33 *** Why Does the Vax retransmit ???? *** Characters = 0 Seq # = 33 Ack # = 371 Characters = 82 Seq # = 371 Ack # = 33 Characters = 0 Seq # = 33 Ack # = 453 - Carl Beame 1017263@MCMASTER.BITNET or BEAME@MCMASTER.BITNET P.S> Any comments or explanations are very welcome. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D27-May-86.05:37:52.CERF] <1986052701370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@USC-ISI.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: A non-routing problem. Message-ID: <[USC-ISI.ARPA]27-May-86.05:37:52.CERF> Date: Tue, 27-May-86 05:37:00 EDT Article-I.D.: <[USC-ISI.ARPA]27-May-86.05:37:52.CERF> Posted: Tue May 27 05:37:00 1986 Date-Received: Tue, 27-May-86 17:57:49 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Aside from bugs, there are a couple of reasons for retransmissions (this is a generic comment, not specific to the VAX code): 1. timeout awaiting ACK leads to retransmissions 2. ACK fails to arrive at all (then see 1 above). Do you know what the path was between the source/sink of this TCP connection? Were there any long delay nets (e.g. SATNET)? Network congestion? Overloaded gateways? Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052701370001> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Tue 27 May 86 02:41:00-PDT Date: 27 May 1986 05:37-EDT Sender: CERF@USC-ISI.ARPA Subject: Re: A non-routing problem. From: CERF@USC-ISI.ARPA To: 1017263%MCMASTER.BITNET@WISCVM.WISC.EDU Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]27-May-86 05:37:52.CERF> In-Reply-To: The message of 26 MAY 86 13:44-EDT from 1017263%MCMASTER.BITNET@WISCVM.WISC.EDU Aside from bugs, there are a couple of reasons for retransmissions (this is a generic comment, not specific to the VAX code): 1. timeout awaiting ACK leads to retransmissions 2. ACK fails to arrive at all (then see 1 above). Do you know what the path was between the source/sink of this TCP connection? Were there any long delay nets (e.g. SATNET)? Network congestion? Overloaded gateways? Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052702182700> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 27 May 86 09:24:27-PDT Date: 27 May 1986 09:18:27 PDT Subject: TCP/IP Vendors Workshop From: Dan Lynch To: TCP-IP@SRI-NIC.ARPA The Internet Activities Board (IAB), in cooperation with DARPA, will hold a TCP/IP Vendors Workshop from 25-27 August, 1986 in Monterey, California. The purpose of the workshop is to bring together the designers of the TCP/IP protocol suite with the implementors of those protocols in the commercial marketplace to go over the meaning of the current protocols and planned future extensions. The workshop will begin with presentations by experts from the research community on the current status of ARPANET and DDN's MILNET, future directions of research, gateway issues, and on migration to ISO standards. Then the workshop will shift into a series of sessions on specific topics (as listed below) that will begin with a statement of known open issues on each topic followed by questions from the implementors for each other or for the the experts. Some sessions topics will undoubtedly need more time than others and topics that have been left out will be accomodated as they arise. Session Topics:: Specifications and Testing: ULANA, Testing/Certification, Assigned Numbers, Official Protocols Files: FTP, TFTP Mail: SMTP, User Mail Agents, MMM, X.400. Telnet: Telnet, Telnet Options Transactions: Domain Names, Remote Procedure Calls Transport: TCP, Retransmission, UDP Network: IP, ICMP, Fragmentation, Security, Precedence (TOS), Gateways (EGP, GGP, IGP), Routing, Subnetting Data Link: ARP, RARP, Address Mapping Physical: 1822, X.25, Ethernet, Token Ring, Token Bus, Satellite, Packet Radio One of the results of the workshop will be an indication of the need for further such workshops or perhaps some other format for exchanging information amongst the multitude of participants in the TCP/IP arena. The list that follows is comprised of companies that are believed to be heavily involved with commercial products in the TCP/IP marketplace. To obtain an invitation to this workshop please contact the Workshop Chair, Dan Lynch. I may be reached at Lynch@USC-ISIB.ARPA or at 408-996-2042. We plan on having two attendees from each company (or separate divisions in some cases) and want to have attendees who are prepared to discuss in detail their implementation problems and suggestions for solutions. If you know of companies that are missing from this list please let me know of them. If you are a customer of commercial TCP/IP products and would like to make sure that your Vendor(s) participate in this workshop please let them know how much you care. ACC, Alliant, Amdahl, Apple, Applitek, Apollo, AT&T, BBN, BDM, Bridge, Burroughs, CDC, Cisco, Computer Network Technology, CMC, Convergent, Convex, Cray, CSC, Data General, Datapoint, DEC, Encore, Elxsi, Excelan, Ford Aerospace, Fortune, Frontier Technologies, FTP Inc., Gould, Honeywell, HP, IBM, Imagen, Intel, Interlan (Micom), Internet Systems Corp., Kinetics, LMI, Locus, Mitre, NCR, Network Research (Oxnard), Network Research (Salt Lake), Network Solutions, NSC, Panda Programming, Perkin-Elmer (now called Concurrent Computing), Plexus, Prime, Process Software, Proteon, Pyramid, QMI, Ridge, SAI, Scope, SDC, Softsel, Spartacus, Sperry, SRI, Sun, Symbolics, Sytek, Tandem, Tektronix, TI, 3Com, Ungermann-Bass, Uniq, Unisoft, Vitalink, Wollongong, Xerox. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605271657.AA09682%40ucbvax.Berkeley.EDU] <1986052708182700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@USC-ISIB.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP Vendors Workshop Message-ID: <8605271657.AA09682@ucbvax.Berkeley.EDU> Date: Tue, 27-May-86 12:18:27 EDT Article-I.D.: ucbvax.8605271657.AA09682 Posted: Tue May 27 12:18:27 1986 Date-Received: Tue, 27-May-86 18:00:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 74 Approved: tcp-ip@sri-nic.arpa The Internet Activities Board (IAB), in cooperation with DARPA, will hold a TCP/IP Vendors Workshop from 25-27 August, 1986 in Monterey, California. The purpose of the workshop is to bring together the designers of the TCP/IP protocol suite with the implementors of those protocols in the commercial marketplace to go over the meaning of the current protocols and planned future extensions. The workshop will begin with presentations by experts from the research community on the current status of ARPANET and DDN's MILNET, future directions of research, gateway issues, and on migration to ISO standards. Then the workshop will shift into a series of sessions on specific topics (as listed below) that will begin with a statement of known open issues on each topic followed by questions from the implementors for each other or for the the experts. Some sessions topics will undoubtedly need more time than others and topics that have been left out will be accomodated as they arise. Session Topics:: Specifications and Testing: ULANA, Testing/Certification, Assigned Numbers, Official Protocols Files: FTP, TFTP Mail: SMTP, User Mail Agents, MMM, X.400. Telnet: Telnet, Telnet Options Transactions: Domain Names, Remote Procedure Calls Transport: TCP, Retransmission, UDP Network: IP, ICMP, Fragmentation, Security, Precedence (TOS), Gateways (EGP, GGP, IGP), Routing, Subnetting Data Link: ARP, RARP, Address Mapping Physical: 1822, X.25, Ethernet, Token Ring, Token Bus, Satellite, Packet Radio One of the results of the workshop will be an indication of the need for further such workshops or perhaps some other format for exchanging information amongst the multitude of participants in the TCP/IP arena. The list that follows is comprised of companies that are believed to be heavily involved with commercial products in the TCP/IP marketplace. To obtain an invitation to this workshop please contact the Workshop Chair, Dan Lynch. I may be reached at Lynch@USC-ISIB.ARPA or at 408-996-2042. We plan on having two attendees from each company (or separate divisions in some cases) and want to have attendees who are prepared to discuss in detail their implementation problems and suggestions for solutions. If you know of companies that are missing from this list please let me know of them. If you are a customer of commercial TCP/IP products and would like to make sure that your Vendor(s) participate in this workshop please let them know how much you care. ACC, Alliant, Amdahl, Apple, Applitek, Apollo, AT&T, BBN, BDM, Bridge, Burroughs, CDC, Cisco, Computer Network Technology, CMC, Convergent, Convex, Cray, CSC, Data General, Datapoint, DEC, Encore, Elxsi, Excelan, Ford Aerospace, Fortune, Frontier Technologies, FTP Inc., Gould, Honeywell, HP, IBM, Imagen, Intel, Interlan (Micom), Internet Systems Corp., Kinetics, LMI, Locus, Mitre, NCR, Network Research (Oxnard), Network Research (Salt Lake), Network Solutions, NSC, Panda Programming, Perkin-Elmer (now called Concurrent Computing), Plexus, Prime, Process Software, Proteon, Pyramid, QMI, Ridge, SAI, Scope, SDC, Softsel, Spartacus, Sperry, SRI, Sun, Symbolics, Sytek, Tandem, Tektronix, TI, 3Com, Ungermann-Bass, Uniq, Unisoft, Vitalink, Wollongong, Xerox. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605271731.AA04204%40isi-braden.arpa] <1986052709312000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI-BRADEN.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP Vendors Workshop Message-ID: <8605271731.AA04204@isi-braden.arpa> Date: Tue, 27-May-86 13:31:20 EDT Article-I.D.: isi-brad.8605271731.AA04204 Posted: Tue May 27 13:31:20 1986 Date-Received: Wed, 28-May-86 00:20:35 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Dan, I don't understand the inclusion of a generic topic "Transactions" or a specific topic "Remote Procedure Call". There is no current or proposed Internet standard in that area... it is being treated as a (quasi-) research topic, which will hopefully lead to a proposed standard at some future time. The domain system deserves to have a major topic all to itself. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052709531100> Received: from isi-venera.arpa by SRI-NIC.ARPA with TCP; Tue 27 May 86 16:54:13-PDT Received: by isi-venera.arpa (5.45/1.2) id AA21456; Tue, 27 May 86 16:53:13 PDT Date: Tue 27 May 86 16:53:11-PDT From: "Joel Goldberger" Subject: Re: {8605.0428} oh mr. postman ... To: Margulies@scrc-yukon.arpa Cc: JOEL%isi-venera.arpa@mc.lcs.mit.edu, tcp-ip@sri-nic.arpa, Joseph@scrc-yukon.arpa, ALNeches%isi-venera.arpa@mc.lcs.mit.edu, Action%USC-ISID.ARPA@mc.lcs.mit.edu, Joel@isi-venera.arpa Message-Id: In-Reply-To: Message from "Benson I. Margulies " of Tue, 27 May 86 18:37 EDT The rejection you are getting is from our SMTP receiver, which (like most mailers) does not parse either the headers or the text of the message. It responds only to the SMTP control lines to form both the return-path line and the received: line. It doesn't like the host specification in the MAIL FROM:<...> SMTP control line. It doesn't care what is sent after the DATA SMTP control line (which is where the "Reply-To: " line is). There are no hard rules on this and our implementation chooses to reject mail where the only host specified is unknown. UNIX is not so rigorous, it will accept mail from (or for) any host whether it exists or not, and will then have no way of informing anyone but the mail system maintainer that there is a problem. We like the TOPS-20 system better where the originator has to resolve the problem. - Joel - ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860527183700.5.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986052714370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SCRC-YUKON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: {8605.0428} oh mr. postman ... Message-ID: <860527183700.5.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Tue, 27-May-86 18:37:00 EDT Article-I.D.: REDWING.860527183700.5.MARGULIES Posted: Tue May 27 18:37:00 1986 Date-Received: Wed, 28-May-86 19:35:56 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 59 Approved: tcp-ip@sri-nic.arpa Date: Tue 27 May 86 14:59:42-PDT From: "Joel Goldberger" Benson, I have been asked to help with your question about our mailers rejection of messages from you. The message you sent to Postmaster claimed a from address of Margulies@SCRC-YUKON.ARPA, but this host didn't appear anywhere in the Received lines. The only hosts in that line are: REDWING.SCRC.Symbolics.com SAPSUCKER.SCRC.Symbolics.com MC.LCS.MIT.EDU Our domain resolvers are unable to find any record for the first two of these hosts. SCRC-YUKON.ARPA is in both the domain and NIC databases. Our TOPS-20 mailers will not accept mail from hosts they cannot resolve. Currently our TOPS-20 systems use the NIC table for all lookups, but in this case a domain based system would not have helped either. You should try to get your mailer to supply at least some honest data concerning the route of outgoing mail. I think that this is reasonable information. The message says on its face: Reply to me by sending to SCRC-YUKON.ARPA. YUKON is a legitimate, visible host. Using the delivery history is flawed. Just because a given chain of machines participated in getting a message out, dosen't mean that it is an appropriate return route. I can sympathize with wanting to toss mail that can't be replied to. However, the restriction should be that mail is returned if none of the return-path, the sender, the reply-to or the from address could be resolved, not if any of them failed to resolve. Furthermore, just because you cannot parse it now, dosen't mean you won't be able to later. Surely you have noticed the rather low availability of most of the domain servers. (as an aside: as a user, I often know more about mail topology than computers, because of the incredibly poor behavior of the domain system [no zone transfers, etc.] Thus, I would prefer to receive this kind of mail rather than haveing the SMTP server do me the favor of dropping it on the ground]. REDWING is my personal machine, which does not offer SMTP, because it has no file system. SAPSUCKER is an internal mail transfer node, used to share outgoing mail load. Yukon is the one and only appropriate place to send me mail, and that's why its in the from line. I have no control over the delivery history. I can't `put something reasonable in it', because it is accumulated as the message goes along. I believe that the protocol states that its purpose is informational, not prescriptive. Even if SAPSUCKER and REDWING were in the host databases, using the return path to return the mail would fail. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(187)%2BTOPSLIB(118).27-May-86.16:53:11.ISI-VENERA.ARPA] <1986052715531100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JOEL@ISI-VENERA.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: {8605.0428} oh mr. postman ... Message-ID: Date: Tue, 27-May-86 19:53:11 EDT Article-I.D.: Posted: Tue May 27 19:53:11 1986 Date-Received: Wed, 28-May-86 19:24:11 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa The rejection you are getting is from our SMTP receiver, which (like most mailers) does not parse either the headers or the text of the message. It responds only to the SMTP control lines to form both the return-path line and the received: line. It doesn't like the host specification in the MAIL FROM:<...> SMTP control line. It doesn't care what is sent after the DATA SMTP control line (which is where the "Reply-To: " line is). There are no hard rules on this and our implementation chooses to reject mail where the only host specified is unknown. UNIX is not so rigorous, it will accept mail from (or for) any host whether it exists or not, and will then have no way of informing anyone but the mail system maintainer that there is a problem. We like the TOPS-20 system better where the originator has to resolve the problem. - Joel - ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12210165659.6.MRC%40SIMTEL20.ARPA] <1986052718031200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@SIMTEL20.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: {8605.0428} oh mr. postman ... Message-ID: <12210165659.6.MRC@SIMTEL20.ARPA> Date: Tue, 27-May-86 22:03:12 EDT Article-I.D.: SIMTEL20.12210165659.6.MRC Posted: Tue May 27 22:03:12 1986 Date-Received: Wed, 28-May-86 19:38:29 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Joel - ISI's SMTP receiver is, as far as I can tell, unique to ISI. The standard TOPS-20 SMTP receiver is my MAISER, which does not validate the host names in MAIL FROM:<...> SMTP commands. The reason it does not validate the host names in the MAIL FROM is that if it did my friends at the NIC would not be able to receive HOSTMASTER mail of the form "Hi, this is FOOBAR, we just got on the net, please add us to the host table"!!!! Since the MAIL FROM host names are only used by the mailer to return failed mail, this isn't a big deal. Failed messages that can't be returned end up in the dead letter mailbox (typically POSTMASTER but not necessarily), where a human can decide whether to keep or toss it out. I ask you not to confuse the two SMTP servers, and I urge the ISI system management to give serious consideration towards adopting the standard SMTP server or at least to implement its willingness to accept mail in spite of possibly bogus return paths. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052718040000> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 28 May 86 01:07:41-PDT Date: 28 May 1986 01:04-PDT Sender: CHASE@USC-ISIB.ARPA Subject: Re: {8605.0428} oh mr. postman ... From: Dale Chase To: MRC@SIMTEL20.ARPA Cc: JOEL@ISI-VENERA.ARPA, Margulies@SCRC-YUKON.ARPA Cc: TCP-IP@SRI-NIC.ARPA, Joseph@SCRC-YUKON.ARPA Cc: Action@USC-ISID.ARPA Message-ID: <[USC-ISIB.ARPA]28-May-86 01:04:26.CHASE> In-Reply-To: <12210165659.6.MRC@SIMTEL20.ARPA> I think the NIC (and probably domain registries) has a unique need to accept mail from unknown hosts, which doesn't apply to hosts in general. The problem with blithely accepting mail with unknown hostnames in the MAIL FROM:<...> control line is that the server is accepting responsibility to either deliver the mail or return a negative acknowledgement. If such a piece of mail turns out to be undeliverable, it does indeed go to the dead letter mailbox. At this point, if the postmaster is good and the phase of the moon is right, the mail will either be forwarded to the intended recipient or returned to the originator. But if the adresses are sufficiently esoteric, the mail just gets dropped (I can remember pre-SMTP days as a Tenex operator when a periodic task was flushing the dead letter mailbox to keep it from overflowing. I wouldn't be surprised if this still happens in some places). And the sender is left wondering why he didn't get an answer to his urgent request. As Joel said, we prefer the originator be notified of the potential problem immediately so it can be straightened out. In this manner, problem resolution is pushed to the most local point possible relative to problem's source. In other words, the user or administrator at site XX is more likely to know that a piece of mail from mumble@frob should really be mumble%frob@XX. <>Dale ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12210199700.14.SY.KEN%40CU20B.COLUMBIA.EDU] <1986052721101100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) Newsgroups: mod.protocols.tcp-ip Subject: Re: {8605.0428} oh mr. postman ... Message-ID: <12210199700.14.SY.KEN@CU20B.COLUMBIA.EDU> Date: Wed, 28-May-86 01:10:11 EDT Article-I.D.: CU20B.12210199700.14.SY.KEN Posted: Wed May 28 01:10:11 1986 Date-Received: Wed, 28-May-86 19:47:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa I would like to second Mark's request to ISI to consider checking out their SMTP mailer software. I don't remember what the exact problem was offhand right now, but I remember we had trouble talking to their mailer, and vice versa. I *think* it had something to do with what I believe was some nonstandard SMTP dialog. /Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISIB.ARPA%5D28-May-86.01:04:26.CHASE] <1986052800040000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Chase@USC-ISIB (Dale Chase) Newsgroups: mod.protocols.tcp-ip Subject: Re: {8605.0428} oh mr. postman ... Message-ID: <[USC-ISIB.ARPA]28-May-86.01:04:26.CHASE> Date: Wed, 28-May-86 04:04:00 EDT Article-I.D.: <[USC-ISIB.ARPA]28-May-86.01:04:26.CHASE> Posted: Wed May 28 04:04:00 1986 Date-Received: Wed, 28-May-86 19:29:43 EDT References: <12210165659.6.MRC@SIMTEL20.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa I think the NIC (and probably domain registries) has a unique need to accept mail from unknown hosts, which doesn't apply to hosts in general. The problem with blithely accepting mail with unknown hostnames in the MAIL FROM:<...> control line is that the server is accepting responsibility to either deliver the mail or return a negative acknowledgement. If such a piece of mail turns out to be undeliverable, it does indeed go to the dead letter mailbox. At this point, if the postmaster is good and the phase of the moon is right, the mail will either be forwarded to the intended recipient or returned to the originator. But if the adresses are sufficiently esoteric, the mail just gets dropped (I can remember pre-SMTP days as a Tenex operator when a periodic task was flushing the dead letter mailbox to keep it from overflowing. I wouldn't be surprised if this still happens in some places). And the sender is left wondering why he didn't get an answer to his urgent request. As Joel said, we prefer the originator be notified of the potential problem immediately so it can be straightened out. In this manner, problem resolution is pushed to the most local point possible relative to problem's source. In other words, the user or administrator at site XX is more likely to know that a piece of mail from mumble@frob should really be mumble%frob@XX. <>Dale ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052802530000> Received: from LOKI.BBN.COM by SRI-NIC.ARPA with TCP; Wed 28 May 86 07:25:52-PDT To: joel@isi-venera.arpa cc: tcp-ip@sri-nic.arpa, margulies@scrc-yukon.arpa Subject: SMTP receiver rejections Date: Wed, 28 May 86 09:33:00 -0400 From: Craig Partridge > There are no hard rules on this and our implementation chooses to reject > mail where the only host specified is unknown. UNIX is not so rigorous, > it will accept mail from (or for) any host whether it exists or not, and > will then have no way of informing anyone but the mail system maintainer > that there is a problem. We like the TOPS-20 system better where the > originator has to resolve the problem. Joel, I generally agree with the goal but do want to point out that our experience at CSNET is that, more often than not, the problem is not the originator's but that of the receiving mail system, which either has out of date host tables (presumably under domains this problem will become one of having a defective or ill-informed nameserver) or some configurational error which causes it to reject the message. Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860528074236.2.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986052803420000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SCRC-YUKON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: {8605.0428} oh mr. postman ... Message-ID: <860528074236.2.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Wed, 28-May-86 07:42:00 EDT Article-I.D.: REDWING.860528074236.2.MARGULIES Posted: Wed May 28 07:42:00 1986 Date-Received: Wed, 28-May-86 20:00:11 EDT References: <[USC-ISIB.ARPA]28-May-86.01:04:26.CHASE> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 43 Approved: tcp-ip@sri-nic.arpa Date: 28 May 1986 01:04-PDT From: Dale Chase I think the NIC (and probably domain registries) has a unique need to accept mail from unknown hosts, which doesn't apply to hosts in general. The problem with blithely accepting mail with unknown hostnames in the MAIL FROM:<...> control line is that the server is accepting responsibility to either deliver the mail or return a negative acknowledgement. If such a piece of mail turns out to be undeliverable, it does indeed go to the dead letter mailbox. At this point, if the postmaster is good and the phase of the moon is right, the mail will either be forwarded to the intended recipient or returned to the originator. But if the adresses are sufficiently esoteric, the mail just gets dropped (I can remember pre-SMTP days as a Tenex operator when a periodic task was flushing the dead letter mailbox to keep it from overflowing. I wouldn't be surprised if this still happens in some places). And the sender is left wondering why he didn't get an answer to his urgent request. As Joel said, we prefer the originator be notified of the potential problem immediately so it can be straightened out. In this manner, problem resolution is pushed to the most local point possible relative to problem's source. In other words, the user or administrator at site XX is more likely to know that a piece of mail from mumble@frob should really be mumble%frob@XX. <>Dale 1) As I have pointed out before, the resolvability of an address varies with time and the domain system. It is never appropriate to ask the question: is this a valid address? and reject because it cannot be domain resolved right now. 2) In-Reply-To and From are in that SMTP spec for a reason, so that mail sending agents can tell mail reading agents how to reply. Mail transmission agents should just follow orders and stay out of the way. Having the SMTP server 'validate' MAIL FROM is a confusion in protocol levels. Personally, I think that MAIL FROM was a bad idea altogether, for this reason. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052803430000> Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by SRI-NIC.ARPA with TCP; Wed 28 May 86 04:45:18-PDT Received: from REDWING.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9601; Wed 28-May-86 07:43:19 EDT Date: Wed, 28 May 86 07:43 EDT From: Benson I. Margulies Subject: Re: {8605.0428} oh mr. postman ... To: Dale Chase , MRC@SIMTEL20.ARPA cc: JOEL%ISI-VENERA.ARPA@MIT-MC.ARPA, TCP-IP@SRI-NIC.ARPA, Joseph@SCRC-YUKON.ARPA, Action%USC-ISID.ARPA@MIT-MC.ARPA In-Reply-To: <[USC-ISIB.ARPA]28-May-86 01:04:26.CHASE> Supersedes: <860528074236.2.MARGULIES@REDWING.SCRC.Symbolics.COM> Message-ID: <860528074328.3.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: 28 May 1986 01:04-PDT From: Dale Chase I think the NIC (and probably domain registries) has a unique need to accept mail from unknown hosts, which doesn't apply to hosts in general. The problem with blithely accepting mail with unknown hostnames in the MAIL FROM:<...> control line is that the server is accepting responsibility to either deliver the mail or return a negative acknowledgement. If such a piece of mail turns out to be undeliverable, it does indeed go to the dead letter mailbox. At this point, if the postmaster is good and the phase of the moon is right, the mail will either be forwarded to the intended recipient or returned to the originator. But if the adresses are sufficiently esoteric, the mail just gets dropped (I can remember pre-SMTP days as a Tenex operator when a periodic task was flushing the dead letter mailbox to keep it from overflowing. I wouldn't be surprised if this still happens in some places). And the sender is left wondering why he didn't get an answer to his urgent request. As Joel said, we prefer the originator be notified of the potential problem immediately so it can be straightened out. In this manner, problem resolution is pushed to the most local point possible relative to problem's source. In other words, the user or administrator at site XX is more likely to know that a piece of mail from mumble@frob should really be mumble%frob@XX. <>Dale 1) As I have pointed out before, the resolvability of an address varies with time and the domain system. It is never appropriate to ask the question: is this a valid address? and reject because it cannot be domain resolved right now. 2) In-Reply-To and From are in that SMTP spec for a reason, so that mail sending agents can tell mail reading agents how to reply. Mail transmission agents should just follow orders and stay out of the way. Having the SMTP server 'validate' MAIL FROM is a confusion in protocol levels. Personally, I think that MAIL FROM was a bad idea altogether, for this reason. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605281447.AA03260%40trantor.UMD.EDU] <1986052806475500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: oconnor@TRANTOR.UMD.EDU (Mike O'Connor) Newsgroups: mod.protocols.tcp-ip Subject: Symbolics TCP/IP Message-ID: <8605281447.AA03260@trantor.UMD.EDU> Date: Wed, 28-May-86 10:47:55 EDT Article-I.D.: trantor.8605281447.AA03260 Posted: Wed May 28 10:47:55 1986 Date-Received: Thu, 29-May-86 07:46:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Does anyone have any comments or caveats concerning the TCP/IP package marketed by Symbolics? Thanks, Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052807344900> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Wed 28 May 86 13:04:44-PDT To: mmdf2@relay.CS.NET, tcp-ip@sri-nic.ARPA Subject: Adaptive SMTP Timeouts Date: Wed, 28 May 86 15:54:49 -0500 From: Craig Partridge I've noticed that a lot of mailers use timeouts on some or all SMTP commands, to make sure that a defective remote mailer doesn't cause the other mailer to hang permanently waiting for a reply. All the code I have seen uses a fixed timeout period. For example, you always have 30 seconds to reply to a HELO, or some such. It has occurred to me that it might make more sense for such mailers to adapt their timeouts to perceived performance at the remote end. For example, I've seen 10-15 second packet round trip times on parts of the Internet. In such a situation, a 30 second timeout is actually a 15 second timeout for the other mailer. One idea for adapting timeouts is to "ping" the other end of the SMTP link with a NOOP command every so often to find out the round trip time, and also get some vague sense of the remote machine's load (since it must actually recognize the NOOP and compose a reply). Another is to simply do one test at the start of the interaction, using the HELO command as the benchmark. What do other people think of this idea?. Anyone got other interesting ways to adjust the timeouts? We're serioiusly considering putting this feature into MMDF2b. Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605281858.AA00664%40ucbvax.Berkeley.EDU] <1986052811020400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: craig@LOKI.BBN.COM (Craig Partridge) Newsgroups: mod.protocols.tcp-ip Subject: SMTP receiver rejections Message-ID: <8605281858.AA00664@ucbvax.Berkeley.EDU> Date: Wed, 28-May-86 15:02:04 EDT Article-I.D.: ucbvax.8605281858.AA00664 Posted: Wed May 28 15:02:04 1986 Date-Received: Thu, 29-May-86 03:14:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa > There are no hard rules on this and our implementation chooses to reject > mail where the only host specified is unknown. UNIX is not so rigorous, > it will accept mail from (or for) any host whether it exists or not, and > will then have no way of informing anyone but the mail system maintainer > that there is a problem. We like the TOPS-20 system better where the > originator has to resolve the problem. Joel, I generally agree with the goal but do want to point out that our experience at CSNET is that, more often than not, the problem is not the originator's but that of the receiving mail system, which either has out of date host tables (presumably under domains this problem will become one of having a defective or ill-informed nameserver) or some configurational error which causes it to reject the message. Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605282054.AA03405%40ucbvax.Berkeley.EDU] <1986052813230700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@SH.CS.NET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Adaptive SMTP Timeouts Message-ID: <8605282054.AA03405@ucbvax.Berkeley.EDU> Date: Wed, 28-May-86 17:23:07 EDT Article-I.D.: ucbvax.8605282054.AA03405 Posted: Wed May 28 17:23:07 1986 Date-Received: Thu, 29-May-86 08:05:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa I've noticed that a lot of mailers use timeouts on some or all SMTP commands, to make sure that a defective remote mailer doesn't cause the other mailer to hang permanently waiting for a reply. All the code I have seen uses a fixed timeout period. For example, you always have 30 seconds to reply to a HELO, or some such. It has occurred to me that it might make more sense for such mailers to adapt their timeouts to perceived performance at the remote end. For example, I've seen 10-15 second packet round trip times on parts of the Internet. In such a situation, a 30 second timeout is actually a 15 second timeout for the other mailer. One idea for adapting timeouts is to "ping" the other end of the SMTP link with a NOOP command every so often to find out the round trip time, and also get some vague sense of the remote machine's load (since it must actually recognize the NOOP and compose a reply). Another is to simply do one test at the start of the interaction, using the HELO command as the benchmark. What do other people think of this idea?. Anyone got other interesting ways to adjust the timeouts? We're serioiusly considering putting this feature into MMDF2b. Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986052819480000> Received: from su-pescadero.arpa by SRI-NIC.ARPA with TCP; Thu 29 May 86 03:22:31-PDT Received: by su-pescadero.arpa with Sendmail; Thu, 29 May 86 03:21:59 pdt Date: 29 May 1986 2:48-PDT From: Steve Deering Subject: time-to-live To: tcp-ip@sri-nic.ARPA Message-Id: <86/05/29 0248.690@su-pescadero.arpa> Please excuse me if this has all been discussed to death in the past, but I'm seeking the answers to the following two questions: (1) Do any existing host or gateway implementations of IP ever decrement the time-to-live field of a IP datagram by more than 1? I.e., does anyone actually check for datagram holding times of more than one second and adjust TTL accordingly? (2) The IP spec (RFC791) says "...every module that processes a datagram must decrease the TTL by at least one...". Is this normally interpreted as including the originating host IP module and/or the final destination host IP module? -- Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- [86.05.29.0248.690%40su-pescadero.arpa] <1986052901480000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: deering@SU-PESCADERO.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: time-to-live Message-ID: <86.05.29.0248.690@su-pescadero.arpa> Date: Thu, 29-May-86 05:48:00 EDT Article-I.D.: su-pesca.86.05.29.0248.690 Posted: Thu May 29 05:48:00 1986 Date-Received: Thu, 29-May-86 23:41:08 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa Please excuse me if this has all been discussed to death in the past, but I'm seeking the answers to the following two questions: (1) Do any existing host or gateway implementations of IP ever decrement the time-to-live field of a IP datagram by more than 1? I.e., does anyone actually check for datagram holding times of more than one second and adjust TTL accordingly? (2) The IP spec (RFC791) says "...every module that processes a datagram must decrease the TTL by at least one...". Is this normally interpreted as including the originating host IP module and/or the final destination host IP module? -- Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605291015.AA16996%40sering.uucp] <1986052904520000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dpk@mcvax.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Adaptive SMTP Timeouts Message-ID: <8605291015.AA16996@sering.uucp> Date: Thu, 29-May-86 08:52:00 EDT Article-I.D.: sering.8605291015.AA16996 Posted: Thu May 29 08:52:00 1986 Date-Received: Thu, 29-May-86 23:41:43 EDT References: <8605282105.AA21234@seismo.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Sounds cute, but is it really necessary. In all cases there should be a reasonable MAXIMUM hardcoded in. I thought the times I put in were reasonable. If not we have to ask should be really be talking to a host whose round trip time is 15 seconds. My suspicion is that the answer might be no. For example, no reply to a HELO after one minute is ridiculous. Sounds like a lot of work to get right and not necessarily foolproof. If you get a really fast HELO response, ar you going to reduce the time on RCPT replies too much (if it needs mucho expansion)? Its very hard to get right in all cases. It may be easier to be able to state difinitively what the values are for all cases. Consider them specs for performance. You need hardcoded minimums and maximums in any case. -Doug- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.BBN.COM%5D29-May-86.09:56:39.CLYNN] <1986052905560000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: CLYNN@A.BBN.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: time-to-live Message-ID: <[A.BBN.COM]29-May-86.09:56:39.CLYNN> Date: Thu, 29-May-86 09:56:00 EDT Article-I.D.: <[A.BBN.COM]29-May-86.09:56:39.CLYNN> Posted: Thu May 29 09:56:00 1986 Date-Received: Sat, 31-May-86 03:20:49 EDT References: <86.05.29.0248.690@su-pescadero.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Steve, The TOPS-20 IP implementation does decrement the Time-to-live field by more than one if the packet has been queued for more than a second. Note however, that this doesn't really apply to the major source of output-queue delay which is in the layer(s) below IP. The timeout for received fragments is set from the time-to-live field, but any additional fragment which is received will reset the timeout to allow fragments from different retransmissions to be combined. The TOPS20 always decrements the Time-to-live, even when it is the originating or receiving host (since the systems support multiple network interfaces and will typically forward packets, route loops could theoretically occur). When a packet is received with a Time-to-live of 1, the packet will be delivered to the higher layers, but not forwarded. Charles Lynn ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605302106.AA16597%40ucbvax.Berkeley.EDU] <1986052910021500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Adaptive SMTP Timeouts Message-ID: <8605302106.AA16597@ucbvax.Berkeley.EDU> Date: Thu, 29-May-86 14:02:15 EDT Article-I.D.: ucbvax.8605302106.AA16597 Posted: Thu May 29 14:02:15 1986 Date-Received: Sat, 31-May-86 03:22:39 EDT Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa In response to the message sent Thu, 29 May 86 12:15:38 +0100 from mcvax!dpk@seismo.CSS.GOV Doug, I commonly see delays of up to a minute for replies to SMTP commands with MIT-MULTICS and up to two minutes for certain FORD-WDL hosts. This, however, bogs the question, since delays of this magnitude would be considered prima facie evidence of brain lesions by almost everybody except their maintainers. On the other hand, premature abandonment of an SMTP connection may be hazardous to the mental health of the recipients. In a recent case when our local 4.2bsd prematurely abandoned an SMTP connection and repeatedly tried it again hour after hour, the recipient got a (truncated) copy of the message every time. After three days he became quite violent. I think SMTP adaptive timeouts, while cute and possibly even useful in some cases, should not be used to "tune" connections, but to ensure system resources are returned to service when something hangs. They should be set quite long - in the order of several minutes. The present situation clearly indicates some implementations are broken and should be fixed. Having said that, it also is clear that the error-recovery characteristics of many mailers and femailers could be much improved. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605292113.AA00579%40tcgould.tn.cornell.edu] <1986052913132200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: garry@TCGOULD.TN.CORNELL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: {8605.0428} oh mr. postman ... Message-ID: <8605292113.AA00579@tcgould.tn.cornell.edu> Date: Thu, 29-May-86 17:13:22 EDT Article-I.D.: tcgould.8605292113.AA00579 Posted: Thu May 29 17:13:22 1986 Date-Received: Sat, 31-May-86 03:24:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: garry%cadif-oak@cu-arpa.cs.cornell.edu Organization: Cornell Engineering && Flying Moose Graphics Lines: 1 Approved: tcp-ip@sri-nic.arpa Why not send a rejection (actually a warning) AND forward the message? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D29-May-86.21:28:26.CERF] <1986052917280000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: CERF@USC-ISI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Adaptive SMTP Timeouts Message-ID: <[USC-ISI.ARPA]29-May-86.21:28:26.CERF> Date: Thu, 29-May-86 21:28:00 EDT Article-I.D.: <[USC-ISI.ARPA]29-May-86.21:28:26.CERF> Posted: Thu May 29 21:28:00 1986 Date-Received: Sat, 31-May-86 15:45:00 EDT References: <8605291015.AA16996@sering.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa Doug, In the complex internet environment, round-trip variations can be significant, depending on the paths taken, the satellite hops, congestion, various failures, and so on. Under jamming conditions, bandwidths drop to increase S/N and also increase delays (unfortunately). At least with respect to DoD objectives, the system has to work even if its parameters exceed the nominally desired limits. Consequently, many of us have been reluctant to rely on any fixed maxima if we can find ways to measure and adapt instead. I don't disagree that it would be easier to declare some maximum and in some instances (e.g. the 576 octet IP packet size which all subsystems must carry without fragmentation) we have done so. But with respect to dynamic parameters such as round-trip time, we have tried hard not to allow ourselves to be bequiled by the apparent simplicity of declared limits. There may well be some other dissenting opinions on this point out there in the diverse world which makes up this interest group, but I believe I am stating the principal view of those of us concerned for DoD requirements. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605300339.AA08753%40COMET.LCS.MIT.Edu] <1986052919392800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: dcf@COMET.LCS.MIT.EDU (David C. Feldmeier) Newsgroups: mod.protocols.tcp-ip Subject: Avalanche Message-ID: <8605300339.AA08753@COMET.LCS.MIT.Edu> Date: Thu, 29-May-86 23:39:28 EDT Article-I.D.: COMET.8605300339.AA08753 Posted: Thu May 29 23:39:28 1986 Date-Received: Sat, 31-May-86 15:52:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa I am doing measurements of the interpacket arrival times for the gateways on a 10 Mbit token ring at MIT, especially our gateway to the ARPANET because it carries the most traffic. While doing these measurements, I noticed that about 35% of the packets arriving at the gateway were only 300 microseconds after the previous packet. Since this is faster than the gateway receives or a single host transmits, I was curious about what was causing it. The problem turned out to be with the 30 VAXs on the ring that run Berkeley 4.2 Unix. A gateway would send a routing packet to the broadcast address and all of the VAXs would not recognize the destination address and forward the packet to the default gateway, which is the gateway to the ARPANET. As soon as the broadcast packet was transmitted, all of the VAXs would simultaneously begin forwarding packets to the gateway as quickly as possible until they got through. The token ring has a data link layer packet acknowledgment, so the VAXs would simply continue in order around the ring with successful host dropping out. Eventually, all would succeed (about 0.13 seconds) and the net would return to normal. The interarrival time of 300 microseconds is because the transmission time of the routing packet is 300 microseconds. The ring was 100% loaded with back-to-back packets for the entire 0.13 seconds. I suspect that on an Ethernet, this would be a bigger mess because of the multiple collisions. -Dave Feldmeier ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12210764483.7.MRC%40PANDA] <1986053000523800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin) Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP Vendors Workshop Message-ID: <12210764483.7.MRC@PANDA> Date: Fri, 30-May-86 04:52:38 EDT Article-I.D.: PANDA.12210764483.7.MRC Posted: Fri May 30 04:52:38 1986 Date-Received: Sat, 31-May-86 15:53:33 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Hi - You can include Panda Programming as being interested in attending this workshop. Our stuff is mostly applications (esp. mail), and we're *very* interested in the X.400 issues, etc. We're also interested in gateway issues and the threatened migration from TCP to TP4. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986053003213300> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 30 May 86 10:25:17-PDT Date: 30 May 1986 10:21:33 PDT Subject: Re: TCP/IP Vendors Workshop From: Dan Lynch To: Mark Crispin cc: LYNCH@USC-ISIB.ARPA, TCP-IP@SRI-NIC.ARPA In-Reply-To: <12210764483.7.MRC@PANDA> Great, Mark. You'll get a packet in about a month. Thanks, Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605311016.AA09322%40ucbvax.Berkeley.EDU] <1986053009213300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: LYNCH@USC-ISIB.ARPA (Dan Lynch) Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP Vendors Workshop Message-ID: <8605311016.AA09322@ucbvax.Berkeley.EDU> Date: Fri, 30-May-86 13:21:33 EDT Article-I.D.: ucbvax.8605311016.AA09322 Posted: Fri May 30 13:21:33 1986 Date-Received: Sat, 31-May-86 22:33:40 EDT References: <12210764483.7.MRC@PANDA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Great, Mark. You'll get a packet in about a month. Thanks, Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605302114.AA21239%40sering.uucp] <1986053020272300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dpk@mcvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Adaptive SMTP Timeouts Message-ID: <8605302114.AA21239@sering.uucp> Date: Sat, 31-May-86 00:27:23 EDT Article-I.D.: sering.8605302114.AA21239 Posted: Sat May 31 00:27:23 1986 Date-Received: Sat, 31-May-86 15:44:00 EDT References: <8605291802.AA21061@seismo.CSS.GOV> Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa For systems that don't have large quantities of mail I have no complaint with large timeouts, but one systems like CSNET-RELAY and BRL which have to process hundreds or thousands of messages a day, waiting minutes can quite a delay if the number of "slow hosts" becomes more than a few. We already have to run 3-4 channels at BRL just to get them mail we have sent. Thinks a 'bout it. It's not an issue I feel strongly enough about to push further, but I want people to think about it. -Doug- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605310436.AA25051%40CLS.LCS.MIT.EDU] <1986053020360000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: james@CLS.LCS.MIT.EDU (James W. O'Toole Jr.) Newsgroups: mod.protocols.tcp-ip Subject: Re: Avalanche Message-ID: <8605310436.AA25051@CLS.LCS.MIT.EDU> Date: Sat, 31-May-86 00:36:00 EDT Article-I.D.: CLS.8605310436.AA25051 Posted: Sat May 31 00:36:00 1986 Date-Received: Sat, 31-May-86 15:57:36 EDT References: <8605300339.AA08753@COMET.LCS.MIT.Edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa From: dcf@comet.lcs.mit.edu (David C. Feldmeier) Subject: Avalanche I suspect that on an Ethernet, this would be a bigger mess because of the multiple collisions. I wouldn't expect multiple collisions, just one: then the ``randomness'' in the backoff times ought to break the symmetry. This is an interesting way to get collisions though. Usually the biggest cause of Ethernet collisions is the transmission of a long packet. If two other hosts become ready to transmit during that time, they will both begin transmitting shortly after the long packet's end. Curious, the gateway's broadcast acts as a synchronizing event, so that the independent transmission times assumption fails. --Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605302157.AA21314%40sering.uucp] <1986053021293300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: dpk@mcvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Adaptive SMTP Timeouts Message-ID: <8605302157.AA21314@sering.uucp> Date: Sat, 31-May-86 01:29:33 EDT Article-I.D.: sering.8605302157.AA21314 Posted: Sat May 31 01:29:33 1986 Date-Received: Sat, 31-May-86 15:56:16 EDT References: <[USC-ISI.ARPA]29-May-86.21:28:26.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa I am aware of DOD operational requirements, as you know. I also have been responsible for real service at a large mail host that essentially talked to every Internet host at the time. My opinions come from this background. While arbitrary limits are to be avoided, there are certain cases when a decision which may help you in a few cases (say a 5 minute response time) can tie up significant resources at other times when a more reasonable timeout would be say 30 seconds. If you can classify hosts or users in one group or the other fine, you can have different classes of response times. But if preclassification is not possible, you have to be careful you don't create more problem that solution. We have had times at BRL when we could not get rid of the mail as fast as it was coming in until we ran seven outbound mail processes simultaneously (with what are now believed to be too short time intervals). Think about it. Novel solutions welcome, but waiting forever is not practical. -Doug- PS. We didn't start out with timeouts, they were added for a reason. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12211031634.9.BILLW%40SU-SCORE.ARPA] <1986053101200800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: BILLW@SU-SCORE.ARPA (William "Chops" Westfield) Newsgroups: mod.protocols.tcp-ip Subject: Avalanche Message-ID: <12211031634.9.BILLW@SU-SCORE.ARPA> Date: Sat, 31-May-86 05:20:08 EDT Article-I.D.: SU-SCORE.12211031634.9.BILLW Posted: Sat May 31 05:20:08 1986 Date-Received: Sat, 31-May-86 22:34:19 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Im pretty sure that I've seen thi problem discussed before - I think as a way to trash microvaxes (somebody sends out an rwhod broadcast packet to the correct (all 1's) address. N Sun workstations think that the broadcast address address ought to be 0, and that the -1 address packet needs to be forwarded (which they all do). the resulting massive and lengthy collision seems to break the DEQNA...) This is the major reason why it is suggested that ip forwarding be turned off on all unixes that aren't actually gateways... BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D31-May-86.08:52:28.CERF] <1986053104520000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: CERF@USC-ISI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Adaptive SMTP Timeouts Message-ID: <[USC-ISI.ARPA]31-May-86.08:52:28.CERF> Date: Sat, 31-May-86 08:52:00 EDT Article-I.D.: <[USC-ISI.ARPA]31-May-86.08:52:28.CERF> Posted: Sat May 31 08:52:00 1986 Date-Received: Sun, 1-Jun-86 01:04:46 EDT References: <8605302157.AA21314@sering.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Doug, these are good points. The line of reasoning which says that timeouts that are too long result in poor resource utilization is on good grounds - the problem I had with an arbitrary maximum is that under some extreme conditions, no service might be provided at all - the usual effect of timeouts that are too short. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12211139364.7.MRC%40PANDA] <1986053111115500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin) Newsgroups: mod.protocols.tcp-ip Subject: Don't throw out your "Internet Mail Protocols"! Message-ID: <12211139364.7.MRC@PANDA> Date: Sat, 31-May-86 15:11:55 EDT Article-I.D.: PANDA.12211139364.7.MRC Posted: Sat May 31 15:11:55 1986 Date-Received: Sun, 1-Jun-86 05:35:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa The NIC has confirmed that RFC 822 was inadvertantly left out of the glossy three-volume DDN Protocol Handbook set. I haven't checked to make sure that the other volumes of the old protocol books are in fact really obsoleted, but considering how important RFC 822 is I would be very careful in throwing out any old documents. Sigh. It's a shame that happened, because otherwise the glossy set is quite a good idea. Is the NIC planning upon more frequent revisions? -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8605312211.AA03618%40gyre.umd.edu] <1986053114114000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: mod.protocols.tcp-ip Subject: Re: Avalanche Message-ID: <8605312211.AA03618@gyre.umd.edu> Date: Sat, 31-May-86 18:11:40 EDT Article-I.D.: gyre.8605312211.AA03618 Posted: Sat May 31 18:11:40 1986 Date-Received: Sun, 1-Jun-86 05:35:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Indeed, it seems to me that IP forwarding should default to `off' on most Unix machines. It also makes sense to disable it if the machine has only one IP interface; this is what 4.3 does. For anyone who has not already done it, IP forwarding may be turned off as follows: 1) binary-only: The first write turns it off in the running kernel; the second turns it off in the boot image. % su [password] # adb -w /vmunix /dev/kmem ipforwarding/W 0 ipforwarding: 1 = 0 ipforwarding?W 0 ipforwarding: 1 = 0 [type ^D here] 2) source: Find the declaration of `ipforwarding' in /sys/netinet/ip_input.c; change it to be initialised to zero. Chris ----MESSAGE-END----