----MESSAGE-BEGIN---- [8805010206.AA21044@ucbarpa.Berkeley.EDU] <1988050102065600> From: fair@UCBARPA.BERKELEY.EDU (Erik E. Fair) Newsgroups: comp.protocols.tcp-ip Subject: ARPANET charging schemes and which protocols are affected? Message-ID: <8805010206.AA21044@ucbarpa.Berkeley.EDU> Date: 1 May 88 02:06:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Does anyone have any hard numbers that document which application protocols are used most over ARPANET (i.e. what TCP & UDP port numbers are seen most often)? It'd be nice if these numbers included both numbers of packets, and number of bytes (since FTP packets are likely to be larger than TELNET packets). The last time I saw any numbers for any part of the Internet, numbers of packets were split: SMTP 30%, FTP 30%, TELNET 30%, and OTHER 10% (this is from memory, so don't take the percentages too literally - it was the relationship between them that I was concerned about at the time). Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050118380000> Received: from vms3.macc.wisc.edu by SRI-NIC.ARPA with TCP; Sun 1 May 88 22:58:53-PDT Received: from VMSmail by vms3.macc.wisc.edu; Sun, 1 May 88 23:38 CDT Message-Id: <11949876615777001@vms3.macc.wisc.edu> Date: Sun, 1 May 88 23:38 CDT From: LIVINGSTONE <@vms3.macc.wisc.edu:LIVINGSTONE@BERT.DecNet> Subject: Re: New BSD TCP/IP & Mt. Xinu To: TCP-IP@SRI-NIC.arpa X-VMS-To: WIRCS3::IN%"TCP-IP@SRI-NIC.arpa" UNSUBSCRIBE TCPIP ----MESSAGE-END---- ----MESSAGE-BEGIN---- [309@orange2.qtp.ufl.edu] <1988050119242800> From: bernhold@qtp.ufl.edu (David E. Bernholdt) Newsgroups: comp.protocols.tcp-ip Subject: Re: Simple Cost Accounting Policy Message-ID: <309@orange2.qtp.ufl.edu> Date: 1 May 88 19:24:28 GMT References: <8804291239.AA21630@jvnca.csc.org> Reply-To: bernhold@orange2.qtp.ufl.edu (David E. Bernholdt) Organization: University of Florida Quantum Theory Project Lines: 23 In article <8804291239.AA21630@jvnca.csc.org> heker@JVNCA.CSC.ORG (Sergio Heker) writes: >Thus I suggest >the fix cost depending on line bandwidth (as I recall Craig Partridge >suggested this before). It seems to me that in the long run this is going to be a problem. If sites are charged based on the bandwidth of their connection to the net, most bean-counters aren't likely to be overly generous with the capacity they are willing to fund. Then nobody is going to have the bandwidth for any more than their own usage & nobody will be willing to sacrifice their much-needed bandwidth to pass somebody else's packets on to another destination. And very quickly the net looses its usefulness. Is my view overly simplistic or too pessimistic (sp?)?? Dave -- David Bernholdt Internet: bernhold@orange.qtp.ufl.edu Quantum Theory Project BITnet: bernhold@ufpine.bitnet University of Florida HEPnet: 43129::59410::bernholdt Gainesville, FL 32611 Phone: 904/392 9306 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050203033800> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Mon, 2 May 88 06:05:46 PDT Date: 2 May 1988 08:03:38 CDT Subject: Networking Classes From: Link@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA cc: LINK@GUNTER-ADAM.ARPA I've got a new employee who's never done any networking before. I'm looking for some good classes for her. I'd like the following topics to be covered: the OSI model, the Internet Community, the DOD model, the MIL-STDs, Ethernet (802.3...), Gateway mechanisms, and an emphasis on local networks. Please reply directly; I no longer monitor TCP-IP. Thanks. |====================================================================| | Link Verstegen Network Solutions, Inc. (NSI) | | Lead Hardware Engineer 4350 Will Rogers Parkway, Suite 100 | | Oklahoma City, OK 73064 | | Link@Gunter-Adam.ARPA (405)942-8884 | |====================================================================| ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050206571600> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Mon, 2 May 88 09:24:54 PDT Received: from RUTVM1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 7840; Mon, 02 May 88 11:11:29 EDT Received: by RUTVM1 (Mailer X1.25) id 8962; Mon, 02 May 88 11:10:47 EDT Date: Mon, 02 May 88 10:57:16 EDT From: Ross Patterson Subject: Re: Another problem with usage charges To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message of Fri, 29 Apr 88 14:18:32 GMT from >Well -- if you read the spec, FTP itself implements checkpoint/restart. >Better protocols may be desirable, but for now we should make the most >of the ones we already have. > >Has anyone implemented checkpoint/restart in FTP? Yup. The UCLA TCP/IP for IBM's MVS system, known as the "ARPANET Control Program", or ACP, supports FTP checkpoint/restart. The Unixes we've got around here dont, since they won't accept a "MODE B" command (Sun's responds "Sorry, only stream mode supported" (or something close to that)). ACP is the basis for most, if not all, IBM MVS implementations. It supports restarting of both transmission and reception, as well as allowing the user control over the interval between checkpoints (defaulting to 100K bytes). Are there any other checkpointers out there? Ross Patterson Rutgers University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050209305200> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Mon, 2 May 88 12:36:48 PDT Date: 2 May 1988 14:30:52 CDT Subject: EDI (ANSI X12) use in the internet From: AFDDN.BEACH@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA cc: AFDDN.BEACH@GUNTER-ADAM.ARPA To any who may know: Can anyone tell me if they're exchanging EDI formatted data across the DoD internet using any of the TCP/Ip protocols? I'm not the least familiar with EDI so if anyone feels like clueing me in, have at it. i do seem to remember something about EDI and TOP being related. Maybe I'm just confused. I'd appreciate any enlightenment anyone can throw my way. Thanks, Darrel Beach ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050209310000> Received: from oregon.uoregon.edu by SRI-NIC.ARPA with TCP; Mon, 2 May 88 16:40:54 PDT Date: Mon, 2 May 88 16:31 PDT From: Dale Smith Subject: potential problems with TTL = 0 To: tcp-ip@sri-nic.arpa X-VMS-To: IN%"tcp-ip@sri-nic.arpa" What is the current "correct" value to place for the TTL field? Can someone with a Sequent Balance 21000 verify what the initial TTL value is for TCP, UDP, and ICMP packets? The reason for this query is that I am having problems delivering mail to uunet.uu.net which is a Sequent Balance 21000. I have observed TCP packets from uunet.uu.net being dropped by my gateway because the TTL was 0. This seems to only happen for TCP traffic. I can ping uunet and get response of 1-2 seconds. I can use nslookup to query uunet.uu.net using datagram (UPD) mode. However, use of any TCP based service to uunet causes lots of TCP packets from uunet to be dropped at my gateway with TTL = 0. I have captured and looked at the UDP and ICMP packets from uunet and they have different, but adequately large TTL values. The folks at uunet say they are running some beta version of TCP/IP. So, is there anyone out there from Sequent who can verify that this is or is not a known problem? Can someone with a Balance 21000 who is running beta-version TCP software look at what the initial TTL value is? Thanks, Dale Smith, Assistant Director of Network Services Internet: dsmith@oregon.uoregon.edu BITNET: dsmith@oregon.bitnet Voice: (503) 686-4394 USmail: University of Oregon Computing Center Eugene, OR 97403-1212 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805030022.AA28096@ucbvax.Berkeley.EDU] <1988050213033800> From: Link@GUNTER-ADAM.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Networking Classes Message-ID: <8805030022.AA28096@ucbvax.Berkeley.EDU> Date: 2 May 88 13:03:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 I've got a new employee who's never done any networking before. I'm looking for some good classes for her. I'd like the following topics to be covered: the OSI model, the Internet Community, the DOD model, the MIL-STDs, Ethernet (802.3...), Gateway mechanisms, and an emphasis on local networks. Please reply directly; I no longer monitor TCP-IP. Thanks. |====================================================================| | Link Verstegen Network Solutions, Inc. (NSI) | | Lead Hardware Engineer 4350 Will Rogers Parkway, Suite 100 | | Oklahoma City, OK 73064 | | Link@Gunter-Adam.ARPA (405)942-8884 | |====================================================================| ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805021750.AA21046@ucbvax.Berkeley.EDU] <1988050214571600> From: A024012@RUTVM1.BITNET (Ross Patterson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Another problem with usage charges Message-ID: <8805021750.AA21046@ucbvax.Berkeley.EDU> Date: 2 May 88 14:57:16 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 >Well -- if you read the spec, FTP itself implements checkpoint/restart. >Better protocols may be desirable, but for now we should make the most >of the ones we already have. > >Has anyone implemented checkpoint/restart in FTP? Yup. The UCLA TCP/IP for IBM's MVS system, known as the "ARPANET Control Program", or ACP, supports FTP checkpoint/restart. The Unixes we've got around here dont, since they won't accept a "MODE B" command (Sun's responds "Sorry, only stream mode supported" (or something close to that)). ACP is the basis for most, if not all, IBM MVS implementations. It supports restarting of both transmission and reception, as well as allowing the user control over the interval between checkpoints (defaulting to 100K bytes). Are there any other checkpointers out there? Ross Patterson Rutgers University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [219@turbo.RAY.COM] <1988050217015000> From: Robin@turbo.RAY.COM (Robin Alston) Newsgroups: comp.dcom.lans,comp.unix.wizards,comp.protocols.tcp-ip Subject: can someone recommend a book covering tcp-ip and nfs? Message-ID: <219@turbo.RAY.COM> Date: 2 May 88 17:01:50 GMT Organization: Raytheon Company, Marlborough MA Lines: 19 Keywords: tcp-ip ethernet NFS Can some kind soul or souls recommend book, books or papers that talk about tcp-ip on the one hand and nfs on the other. It looks like I am going to be implementing a port of nfs to some of our hardware and we have a source based on the SGI 3000 series workstations (which our whole system is kind of based on). I will be involved initially with the low level talking bits and packets on the ethernet board first but migrating up to nfs soon after that. We also intend to implement a multi-processor unix using nfs but communicating tcp-ip on the normal system bus, any recommended reading here might be useful too. ta v mucho. -- ------------------------------------------------- # Whats worse than two MA drivers on a freeway? # Dr. Robin the REAL # Answer: One Toronto driver # SuperUser Atilla! ------------------------------------------------- (617)-460-8225 Robin@turbo.ray.com .....!rayssd!turbo!Robin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050217160000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon, 2 May 88 18:19:39 PDT Date: 2 May 1988 21:16-EDT Sender: CERF@A.ISI.EDU Subject: Re: Networking Classes From: CERF@A.ISI.EDU To: Link@GUNTER-ADAM.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 2-May-88 21:16:51.CERF> In-Reply-To: The message of 2 May 1988 08:03:38 CDT from Link@GUNTER-ADAM.ARPA Send her to one of Dan Lynch's tutorial sequences - he just did a good one in Washington, DC. Dan runs Advanced Computing Environments out of Palo Alto, CA (on San Antonion Roa). He can be reached as Lynch@ISI.EDU. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805021757.AA06804@GAAK.LCS.MIT.EDU] <1988050217573600> From: map@GAAK.LCS.MIT.EDU (Michael A. Patton) Newsgroups: comp.protocols.tcp-ip Subject: Many things on ethernet together??? Message-ID: <8805021757.AA06804@GAAK.LCS.MIT.EDU> Date: 2 May 88 17:57:36 GMT References: <218@turbo.RAY.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 Date: 29 Apr 88 19:38:16 GMT From: rayssd!turbo!Robin@gatech.edu (Robin Alston) Organization: Raytheon Company, Marlborough MA My question is can this really work? Can XNS and TCP-IP share the same coax cable with no possible problems? Can we have our own domain (we really have no interest at this time in talking to our vaxes), while decnet has its own on the same cable? There is no problem at all with this, Ethernet was designed with exactly this type of thing in mind (of course ISO is different, but can be made to coexist with a simple kludge). We have one Ethernet here that carries TCP/IP, XNS and ChaosNet (that I know of, I'm sure there are others that nobody bothers to tell me about) at the same time. In fact the MicroVAX that I use as a workstation runs both TCP/IP and ChaosNet on the same interface without any problem. The designers of Ethernet assumed there would be multiple higher level protocols and provided a field in the Ethernet packet to say which one it carried. Any reasonable Ethernet driver should just calmly ignore (maybe count) any packets with a type field it doesn't recognize. Michael A. Patton Network Manager Lab. for Comp. Sci. Mass. Inst. of Tech. P.S. For those who don't know the kludge for coexistance mentioned in the body, ISO replaces the Ethernet type field with a length field which occupies the same bits. Coincidentally Ethernet types are illegal ISO lengths and vice-versa, this allows the software to tell them apart, you could look at it as assigning ISO a large number of Ethernet type codes, which they then select between to encode the length of the packet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10678@steinmetz.ge.com] <1988050219022600> From: davidsen@steinmetz.ge.com (William E. Davidsen Jr) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together??? Message-ID: <10678@steinmetz.ge.com> Date: 2 May 88 19:02:26 GMT References: <218@turbo.RAY.COM> Reply-To: davidsen@crdos1.UUCP (bill davidsen) Organization: General Electric CRD, Schenectady, NY Lines: 8 Keywords: TCP-IP. XNS. DECNET. You can put a LOT of still on one cable. The limiting factor is the traffic, not the number of devices (until you reach the addressing limit). I would not expect to see any trouble, and you can get software for the VMS machines to enable sending SMTP mail to them. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me ----MESSAGE-END---- ----MESSAGE-BEGIN---- [14505@sgi.SGI.COM] <1988050219140000> From: vjs@rhyolite.SGI.COM (Vernon Schryver) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Message-ID: <14505@sgi.SGI.COM> Date: 2 May 88 19:14:00 GMT References: <218@turbo.RAY.COM> Sender: daemon@sgi.SGI.COM Organization: Silicon Graphics Inc, Mountain View, CA Lines: 33 Keywords: TCP-IP. XNS. DECNET. Summary: TCP & XNS?--no problem In article <218@turbo.RAY.COM>, Robin@turbo.RAY.COM (Robin Alston) writes: > > We have a bunch of SGI workstations currently running XNS over ethernet. > We have just been informed that when we move into a new building at the > end of May we will have to use a single ethernet cable for the whole > building which includes many vaxen running VMS many many pc's with some kind > of future-net link and many pc's with simple vax links. > > My question is can this really work? > Can XNS and TCP-IP share the same coax cable with no possible problems? > Can we have our own domain (we really have no interest at this time in > talking to our vaxes), while decnet has its own on the same cable? We have converted our ever growing network from our XNS to TCP. Two years ago, we had ~100 workstations, some VAXes, and other stuff, all on one cable. We used XNS almost exclusively, even on the VAXes. We now have lots more workstations, more VAXes (VMS, 4.2+XNS+TCP, 4.3+NFS), PC-clones running TCP, many cables, routers (our own, of course), bridges, microwaves, an APRANET connection (also, of course, our own box--please forgive the commercial), using almost exclusively TCP/IP/UDP. The conversion was continuous; for most percentages n between 1 and 100, we have had n% TCP and (100-n)% XNS, without trouble. We also mix DECnet with TCP & XNS on the same cable, using IRIS's & VAXes to gateway between TCP & DECnet. We have been blessed with other, educational troubles. For example, consider what groups of IRIS 4D's running the UDP-broadcast version of 'dog' at >30 frames/sec do to 750's, which think anything more than 20 broadcast packets/sec is a catastrophic storm. Vernon Schryver Silicon Graphics vjs@sgi.com {decwrl,sun,pyramid,research,allegra,ucbvax}!sgi!vjs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805030624.AA04157@ucbvax.Berkeley.EDU] <1988050219305200> From: AFDDN.BEACH@GUNTER-ADAM.ARPA Newsgroups: comp.protocols.tcp-ip Subject: EDI (ANSI X12) use in the internet Message-ID: <8805030624.AA04157@ucbvax.Berkeley.EDU> Date: 2 May 88 19:30:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 To any who may know: Can anyone tell me if they're exchanging EDI formatted data across the DoD internet using any of the TCP/Ip protocols? I'm not the least familiar with EDI so if anyone feels like clueing me in, have at it. i do seem to remember something about EDI and TOP being related. Maybe I'm just confused. I'd appreciate any enlightenment anyone can throw my way. Thanks, Darrel Beach ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805030717.AA05200@ucbvax.Berkeley.EDU] <1988050223310000> From: DSMITH@OREGON.UOREGON.EDU (Dale Smith) Newsgroups: comp.protocols.tcp-ip Subject: potential problems with TTL = 0 Message-ID: <8805030717.AA05200@ucbvax.Berkeley.EDU> Date: 2 May 88 23:31:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 What is the current "correct" value to place for the TTL field? Can someone with a Sequent Balance 21000 verify what the initial TTL value is for TCP, UDP, and ICMP packets? The reason for this query is that I am having problems delivering mail to uunet.uu.net which is a Sequent Balance 21000. I have observed TCP packets from uunet.uu.net being dropped by my gateway because the TTL was 0. This seems to only happen for TCP traffic. I can ping uunet and get response of 1-2 seconds. I can use nslookup to query uunet.uu.net using datagram (UPD) mode. However, use of any TCP based service to uunet causes lots of TCP packets from uunet to be dropped at my gateway with TTL = 0. I have captured and looked at the UDP and ICMP packets from uunet and they have different, but adequately large TTL values. The folks at uunet say they are running some beta version of TCP/IP. So, is there anyone out there from Sequent who can verify that this is or is not a known problem? Can someone with a Balance 21000 who is running beta-version TCP software look at what the initial TTL value is? Thanks, Dale Smith, Assistant Director of Network Services Internet: dsmith@oregon.uoregon.edu BITNET: dsmith@oregon.bitnet Voice: (503) 686-4394 USmail: University of Oregon Computing Center Eugene, OR 97403-1212 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU].2-May-88.21:16:51.CERF] <1988050301160000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Networking Classes Message-ID: <[A.ISI.EDU].2-May-88.21:16:51.CERF> Date: 3 May 88 01:16:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Send her to one of Dan Lynch's tutorial sequences - he just did a good one in Washington, DC. Dan runs Advanced Computing Environments out of Palo Alto, CA (on San Antonion Roa). He can be reached as Lynch@ISI.EDU. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050309020000> Received: from ddn3.arpa by SRI-NIC.ARPA with TCP; Tue, 3 May 88 10:26:51 PDT Date: 3 May 88 13:02 EDT From: Corrigan @ DDN3.ARPA Subject: FTP Checkpoint To: tcp-ip @ sri-nic.arpa The FTP implementation on the Honeywell mainframe done for the World-Wide Military Command and Control System (WWMCCS) implements and uses checkpoint/ restart. It also lets you begin a transfer, leave, and check back later on status. They used to move huge files in the mid/late 70's and restart was essential for operational, not cost, reasons, because the system didn't stay up long enough to complete very many transfers. The checkpoints were based o time, not number of records transfered, because the variability in throughput was high, and minimizing the amount of lost time was the important issue. I think 5 minutes between checkpoints was the default. All this continues to work as we speak -- of course the protocol it is running over is NCP...... Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4743@teddy.UUCP] <1988050314055700> From: rdt@teddy.UUCP (Ron D. Thornton) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP for Dec RT11 or DG RDOS Message-ID: <4743@teddy.UUCP> Date: 3 May 88 14:05:57 GMT References: <2886@emory.uucp> Reply-To: rdt@teddy.UUCP (Ron D. Thornton) Organization: GenRad, Inc., Concord, Mass. Lines: 7 Process Software Corp has a version of TCP/IP for RT-11 SJ, FB, or XM. While I did have a different opinion about what constituted bugs (broadcast storms and static host names in the arp table) they have improved the product and it does fit on an RT-11 system. Process Software - Amherst, MA - (413) 549-6994 -Ron- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12395376343.29.LYNCH@A.ISI.EDU] <1988050314355200> From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: can someone recommend a book covering tcp-ip and nfs? Message-ID: <12395376343.29.LYNCH@A.ISI.EDU> Date: 3 May 88 14:35:52 GMT References: <219@turbo.RAY.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Robin, You should read Doug Comer's new book on TCP/IP. "Internetworking with TCP/IP, Prentice Hall, ISBN 0-13-470154-2. And, you should come to Monterey next Monday to attend a two day seminar on TCP Performance taught by Van Jacobsen and Mike Karels of Berkeley. My company, Advanced Computing Envrionments is sponsoringn it, so I have some prejudice. next week is probably too son for any bureaucracy to move, but it is really your best bet for getting tons of good info in a hurry. Dan 415-941-3399 PS. Send me your US Snail addres so we can keep you informed of future events. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050316072800> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Fri, 6 May 88 05:05:01 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA17417; Tue, 3 May 88 14:25:47 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 May 88 16:07:28 GMT From: sundc!hadron!rlgvax!dennis@seismo.css.gov (Dennis.Bednar) Organization: Computer Consoles Inc, Reston VA Subject: Novell and TCP-IP interoperability Message-Id: <934@rlgvax.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa [The message below is posted for another CCI employee. Please send replies to me, and I will forward to him. Thanks. dennis] MICOM TCP Gateway for Novell Netware I am looking for a site that has installed the MICOM TCP Gateway for Novell Netware connected specifically to a UNIX system. They use their NP600G board in the file server. The board allows PC's connected to the Novell file server to log on a UNIX system. For my purposes it doesn't matter what topology they are using ( token ring, starlan etc. ) but it does need to be connected to ethernet. I understand the gateway works great but I need to reference a site. If anyone knows of a site that is using this board please let me know. Thanks in advance for any help. BILL BURCH -- FullName: Dennis Bednar UUCP: {uunet|sundc}!rlgvax!dennis USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091 Telephone: +1 703 648 3300 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805040532.AA25778@ucbvax.Berkeley.EDU] <1988050317020000> From: Corrigan@DDN3.ARPA Newsgroups: comp.protocols.tcp-ip Subject: FTP Checkpoint Message-ID: <8805040532.AA25778@ucbvax.Berkeley.EDU> Date: 3 May 88 17:02:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 The FTP implementation on the Honeywell mainframe done for the World-Wide Military Command and Control System (WWMCCS) implements and uses checkpoint/ restart. It also lets you begin a transfer, leave, and check back later on status. They used to move huge files in the mid/late 70's and restart was essential for operational, not cost, reasons, because the system didn't stay up long enough to complete very many transfers. The checkpoints were based o time, not number of records transfered, because the variability in throughput was high, and minimizing the amount of lost time was the important issue. I think 5 minutes between checkpoints was the default. All this continues to work as we speak -- of course the protocol it is running over is NCP...... Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1780@carthage.UUCP] <1988050318395800> From: jeremy@swatsun.uucp (Jeremy Brest) Newsgroups: comp.protocols.tcp-ip,comp.os.vms,comp.protocols.misc,comp.protocols.appletalk Subject: Any experiences w/ DECnet in a multi-vendor environment? Message-ID: <1780@carthage.UUCP> Date: 3 May 88 18:39:58 GMT Reply-To: jeremy@swatsun.UUCP (Jeremy Brest) Organization: Swarthmore College, Swarthmore PA Lines: 35 Keywords: DECnet, TCP-IP I'm interested in any experiences that anyone has had with trying to use DECnet as the central protocol in a multi-vendor network environment. How well (i.e., transparently) do the following work? 1) remote login to local sites? 2) remote login to wide area TCP-IP networks? 3) file transfer between local sites? 4) file transfer (anonymous FTP) over wide area TCP-IP networks? 5) local mail? 6) mail through wide area networks, including uucp, bitnet, wide area TCP-IP networks, and CSNet? Other concerns are how Macintoshes and MS-DOS machines fit into the picture. I know that with TCP-IP, software has been developed to provide login and file transfer, as well as sever implementations of mail systems. What about with DECnet? I'm also interested in how might a heterogenious network work out, that is, have a few machines that spoke both TCP-IP and DECnet, but most machines speaking one or the other. Thanks, Jeremy Brest Swarthmore College uucp: ...seismo!bpa!swatsun!jeremy CSnet: jeremy@swatsun.swarthmore.edu Internet: jeremy%swatsun.swarthmore.edu@relay.cs.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [May.3.16.55.17.1988.4444@topaz.rutgers.edu] <1988050320551900> From: ron@topaz.rutgers.edu (Ron Natalie) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together??? Message-ID: Date: 3 May 88 20:55:19 GMT References: <218@turbo.RAY.COM> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 5 Keywords: TCP-IP. XNS. DECNET. XNS and TCP/IP will coexist on an Ethernet. They use different Ethernet Type numbers. I have the TCP/IP version of flight simulator when you're ready. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1640@lll-lcc.aRpA] <1988050321235500> From: wiltzius@lll-lcc.aRpA (Dave P. Wiltzius) Newsgroups: comp.protocols.tcp-ip Subject: Raw Sockets Message-ID: <1640@lll-lcc.aRpA> Date: 3 May 88 21:23:55 GMT Reply-To: wiltzius@lll-crg.UUCP (Dave P. Wiltzius) Organization: CRG, Lawrence Livermore Labs Lines: 16 I'm being a bit lazy here: I want to use an IP raw socket to implement a non-Internet transport protocol on IP (please, this is an exercise and not my idea). The particular UNIX system is Sun's 3.2. Can only "super-user" use the IP raw socket? I suspect this is a silly question, but can there only be one process on the system using the IP raw socket? For those of you that did this (as it was intended) to prototype and debug transport code, what was the difference in performance between the raw socket implementation and the kernel implementation. Any comments as an aside would be welcome - perhaps more appropriately as E-mail. Thank you. -------------------------------------------------------------------- Dave Wiltzius (wiltzius@lll-lcc.llnl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1068@thumper.bellcore.com] <1988050323102000> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Another problem with usage charges Message-ID: <1068@thumper.bellcore.com> Date: 3 May 88 23:10:20 GMT References: <8805030046.AA28508@ucbvax.Berkeley.EDU> Organization: Bell Communications Research, Inc Lines: 25 Summary: abuse of refund procedures The discussion of refunding aborted FTPs reminds me of a common trick among the Cornell RJE terminal operations staff back during my undergrad hacking days. The system (IBM OS/360, batch oriented) charged for each line actually printed. However, since line printers jam from time to time, the RJE operator could command the system to restart a print job from the beginning, canceling the charges for the copy already printed. But it became common practice among those operators whose funny-money accounts were running low to add several pages of unneeded garbage to their job output. When the useful stuff had all been printed, they would restart the job and then kill it, thus costing them NOTHING for the output they did print. Clearly any FTP refund scheme would invite exactly the same sort of abuse. On the other hand, I would like to repeat a quote I saw on the net almost 10 years ago. I wish I could remember who said it. It seems relevant to the subject at hand: "There may be no such thing as a free lunch, but sometimes it costs more to collect money than to give away food". Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [11928@shemp.CS.UCLA.EDU] <1988050404441600> From: wales@CS.UCLA.EDU Newsgroups: sci.research,comp.protocols.tcp-ip Subject: Research on protocol optimization for slow networks? Message-ID: <11928@shemp.CS.UCLA.EDU> Date: 4 May 88 04:44:16 GMT Sender: news@CS.UCLA.EDU Reply-To: wales@CS.UCLA.EDU (Rich Wales) Organization: UCLA CS Department, Los Angeles Lines: 23 I am looking for any leads to recent research on the question of how to improve the performance of a communications protocol to make it more acceptable for use over a "slow" network link. By "slow", I am thinking (roughly speaking) of 9600 bits/sec or slower for interactive work. If the application involves transfer of large amounts of data, then some people might consider faster links (e.g., 56K bits/sec) to be "slow". I'm open to the possibility of improving protocol performance at any or all levels. I haven't tried to narrow myself down very much yet. I'm aware, for instance, of the work of various high-speed modem manu- facturers in implementing data compression and/or certain protocols in their modems (e.g., Telebit's UUCP packet protocol implementation). But I haven't had much luck in finding other material. Any pointers to current or recent research in this area would be grate- fully appreciated. -- Rich Wales // UCLA CS Dept // wales@CS.UCLA.EDU // +1 (213) 825-5683 3531 Boelter Hall // Los Angeles, California 90024-1596 // USA ...!(ucbvax,rutgers)!ucla-cs!wales ...!uunet!cs.ucla.edu!wales "Mr. LaForge, when I left this ship it was in one piece!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880503-224006-1394@Xerox] <1988050405400400> From: RMRichardson.PA@XEROX.COM (Rich) Newsgroups: comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Message-ID: <880503-224006-1394@Xerox> Date: 4 May 88 05:40:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: RMRichardson.PA@Xerox.COM Organization: The Internet Lines: 22 In article <51442@sun.uucp> limes@sun.com (Greg Limes) writes: > In article <218@turbo.RAY.COM> Robin@turbo.RAY.COM (Robin Alston) writes: > >Can XNS and TCP-IP share the same coax cable with no possible problems? > ... It is even possible (gag) to run both TCP/IP and XNS through the same > physical interface, but the bottom layer does need to know where to send > each packet type. ... My workstation can talk PUP, XNS and TCP/IP simultaneously, i.e., three connections at once, all on the same wire. I make no claims about speed, etc., just that it can be done, so you should be able to do the same. > >Can we have our own domain (we really have no interest at this time in > >talking to our vaxes), while decnet has its own on the same cable? This should be ok; the fun part comes when you do want to talk to each other. Then you need an XNS package on the vaxes, or TCP-IP on your other machines. Rich ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050410424500> Received: from csli.stanford.edu by SRI-NIC.ARPA with TCP; Wed, 4 May 88 19:22:58 PDT Received: by csli.stanford.edu (3.2/4.7); Wed, 4 May 88 17:42:45 PDT Date: Wed, 4 May 88 17:42:45 PDT From: croft@csli.stanford.edu (Bill Croft) To: tcp-ip@sri-nic.ARPA Subject: re: Public Domain Software for BOOTP Cc: croft@csli.stanford.edu, karwowska@dg-rtp.dg.com > Date: 28 Apr 88 19:11:28 GMT > From: rti!xyzzy!karwowska@mcnc.org (Joanna Karwowska) > Subject: Public Domain Software for Bootp > > I would like to get an access to the public domain software > for remote bootstrap protocol - bootp (RFC951). > Can anybody help? > > Joanna Karwowska > karwowska@dg-rtp.dg.com > Data General, Research Triangle Park, NC > !mcnc!rti-sel!rtp46!karwowska You can anonymous FTP the files 'bootp.client.shar' and 'bootp.server.shar' from the pub directory on safe.stanford.edu. The client code autoconfigures to find and boot from a couple of different ether interfaces (3COM/Interlan). The server runs under 4.X BSD UNIX. A number of vendors are now supporting this boot mechanism. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805041439.AA02613@chakra.cs.umd.edu] <1988050414393100> From: dheeraj@chakra.cs.umd.EDU Newsgroups: comp.protocols.tcp-ip Subject: LSRR option in IP Message-ID: <8805041439.AA02613@chakra.cs.umd.edu> Date: 4 May 88 14:39:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 I have been trying to use LSRR option of IP to route a packet through various machines on the campus. Most machines just drop the packet. I went into the ip_input code. It seems that ip_forward(ip, ifp) drops the packet if 1. ipforwarding is off OR 2. in_interfaces is <= 1 That means that hosts with only one interface cannot have packets loose source routed through them. I don't understand why this should be the case. If some Gateway is trying to route the packet through this machine, then it make sense to let the Gateway know that it is inefficient to route the packet this way but if a user is forcing the packet through this machine then I don't see why should the packet be dropped. Actually, if the machine has more than one interfaces and the routing alogrithm decides to forward the packet through the same interface as it came on then the packet is not dropped. (Isn't it similar to having one interface and forwarding the packet through the same one.) Thanks, dheeraj sanghi ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805061444.AA21266@ucbvax.Berkeley.EDU] <1988050500424500> From: croft@CSLI.STANFORD.EDU (Bill Croft) Newsgroups: comp.protocols.tcp-ip Subject: re: Public Domain Software for BOOTP Message-ID: <8805061444.AA21266@ucbvax.Berkeley.EDU> Date: 5 May 88 00:42:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 You can anonymous FTP the files 'bootp.client.shar' and 'bootp.server.shar' from the pub directory on safe.stanford.edu. The client code autoconfigures to find and boot from a couple of different ether interfaces (3COM/Interlan). The server runs under 4.X BSD UNIX. A number of vendors are now supporting this boot mechanism. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050513031100> Received: from OFFICE-1.ARPA by SRI-NIC.ARPA with TCP; Thu, 5 May 88 16:06:03 PDT Received: from F29.Tymnet by OFFICE-1.ARPA; 5 May 88 16:04:44 PDT Received: from SLVMCL1.McAuto.Tymnet by F29.Tymnet; Thu, 5 May 88 16:04:21 PDT From: Keith R. Hacke Date: 05/05/88 18:03:11 To: Subject: Wollongong's TCP/IP We are planning to purchase Wollongong's TCP/IP implementation for a MicroVAX running VMS. I am particularly interested in its use for Domain Name Serving between our Ethernet and the DDN (we have a Milnet connection). VMS is used on our VAXs, UNIX on the Suns and Silicon Graphics. What do you think of Wollongong's TCP/IP? Is anyone using it for Domain Name Serving? With a VAX running VMS? Other ideas (I know about using a Sun for the Domain Server)? Thanks Keith R. Hacke McDonnell Douglas 314-895-5343 PS Thanks to those who gave info on D. Comer's TCP/IP book. Our company library is getting it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1607@erix.UUCP] <1988050513273100> From: per@erix.UUCP (Per Hedeland) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Subnetting Message-ID: <1607@erix.UUCP> Date: 5 May 88 13:27:31 GMT Reply-To: per@erix.ericsson.se (Per Hedeland) Organization: Ericsson Telecom, Stockholm, Sweden Lines: 46 Excuse me if the question below is trivial, but I really haven't seen much discussion on subnetting, and neither RFC reading nor local asking-around has gotten me very far... This is the scenario: The basic structure of our LAN is a backbone segment, to which a number of Sun server/client groups are connected. Each client group has it's own Ether segment, with the server acting as gateway to the backbone. Typically there are 5-10 clients in each group. There are currently some 20 such groups, but predictions are for hundreds in the not too distant future, i.e. considering other connected equipment, far more than 256 addresses are required for the backbone. Due to us not being connected to the Internet, and inadequate planning of the growth of the LAN, network numbering is a mess, which we would like to clean up as soon as possible, and this prompts my question: It seems to be a terrible waste of adress space to use a separate class C number for each of the client groups, so we figured that subnetting would be appropriate, but how do we use it to an advantage? Specifically, given the abovementioned structure, there's a conflict between: a) It appears that the intended use of subnetting assumes that all the "subs" of a "whole" net are interconnected, i.e. the backbone and the client segments in our case should be "subs" of the same "whole" - in particular, "automatic" routing by means of routed (which we desire) will not work otherwise, as far as I can understand. and: b) "Subs" of a given "whole" must be of equal size. We do believe that the arguments for the current structure (such as handling the load from diskless clients, avoiding extra cabling given the physical location of servers and clients, allowing use of the backbone for e.g. DECnet traffic) are valid, and it seems rather silly having to modify it to accommodate the IP adressing scheme. But of course, neither the structure nor the requirement for "automatic" routing are carved in stone, i.e. any and all suggestions are welcome (preferrably via e-mail, and I will summarize to the net if requested). Thanks In Advance --Per Hedeland Internet: per@erix.ericsson.se Non-MX: per%erix.ericsson.se@uunet.uu.net UUCP: {mcvax,munnari,uunet}!enea!erix!per ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4307@dcatla.UUCP] <1988050513294100> From: dnwcv@dcatla.UUCP (William C. VerSteeg) Newsgroups: comp.protocols.tcp-ip Subject: Bootp information Message-ID: <4307@dcatla.UUCP> Date: 5 May 88 13:29:41 GMT Reply-To: dnwcv@dcatla.UUCP (William C. VerSteeg) Organization: DCA Inc., Alpharetta, GA Lines: 14 This is a request for information on the Bootp protocol. As I understand it, this protocol allows a dumb device to be loaded from from a server device. I am particularly interested to know if the protocol works using IP routers, subnets, fragmentation, etc. Also an approximation of the PROM space required to contain enough of this code to boot a device from power-up (i.e. one that doesn't know its own IP address) Please send a pointer to the apropriate information to me directly. I will summarize to the net if there is enough interest. Thanks in Advance Bill VerSteeg ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050514303200> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Sat, 7 May 88 13:31:48 PDT Received: from VTVM1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4416; Thu, 05 May 88 18:31:36 EDT Received: by VTVM1 (Mailer X1.25) id 3828; Thu, 05 May 88 18:31:04 EDT Date: Thu, 05 May 88 18:30:32 EDT From: Lyle Evans Subject: Federation of American Research Networks (FARnet) To: TCP-IP@SRI-NIC.ARPA Sergio Heker writes > ... >As a point of information, there is a task force whithin the Federation >of American Research Networks (FARnet), working on this issue right now. Could somebody give me some more information about the Federation of American Research Networks FARnet ? Lyle Evans (Bitnet: Evansl @ VTVM1 ) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [QWU7zPy00W0rM0aWl0@andrew.cmu.edu] <1988050514444300> From: ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) Newsgroups: comp.protocols.tcp-ip Subject: Whither Chargeback Message-ID: Date: 5 May 88 14:44:43 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 64 The issues being discussed here regarding chargeback are faced regularly by every corporation which has a private telecommunications network. Consider the following: 1. What to do when different networks have different prices? This is eminently true of today's telecommunications providers. MCI, AT&T, and Sprint all have different price schedules. You can buy leased lines with flat rates for service up to a bandwidth limit, WATS lines which are distance insensitive but usage priced (after a minimum), and regular Direct Distance Dialed (DDD) service which is priced by both time and distance. Corporations buy Private Branch Exchanges (PBXs) with Least Cost Routing (LCR) software which decides on a call-by-call basis which network to use. Calls go by preference over leased lines since you've paid for them anyway. If the leased line is busy, there are several alternatives: a) you get a busy signal and the client places the call again, perhaps specifying an alternate carrier; b) the call automatically overflows onto the next highest cost facility. As to chargeback in this environment, again there are several approaches. You can calculate the average cost per minute over the various networks (leased lines, WATS, etc.) for all calls from A to B and use that as the basis for chargeback. This puts the burden on the telecom manager to optimize the LCR and the facilities to minimize total costs. Or, particularly with option a) above, the user pays the cost for the facility used; if he replaces the call on the DDD network rather than waiting for the tie line to become free, he pays a higher price for the call. Time of day pricing leads users to defer traffic such as mail to off peak hours. This reduces the peak traffic and the corresponding network capacity required. There are lots of variations in between. 2. Connection charges versus usage charges. Both are clearly required. Much of the network cost is in access, so connection charges should probably recover a large chunk of the total cost. But usage charges are also important: how else do you justify investing in that FTP implementation that uses the restart facility? Usage charges create incentives to write better software (or to go out and buy better software) that will cut the usage cost. In the same way, time usage charges on DDD networks lead customers to justify buying higher speed modems or data compression boxes. Right now, there is only the small incentive of minimizing processor interrupts to get people to write network code that does sensible thinks about packet acknowledgements. 3. Money for capacity expansion. In the U.S. the carriers have always financed capacity expansion out of profits or borrowing. In Europe, for example France before 1970, capacity expansion had to be funded out of legislative appropriations; all profits were returned to the treasury. Anyone who ever tried to use a phone in France before 1970 knows how the French underfunded capacity expansion under this regime. Corporations without chargeback to the internal users have the same problem justifying appropriations from corporate budget directors. 4. Volume discounts. Volume discounts can make usage charges fair to both large users and smaller ones. After all, a T1 link costs less than 24 56 kbps links; large users enable the network to buy more cost effective transmission links. We have volume discounts for electric power and for telecommunication users in the commercial world. 4. Cross subsidies. There should be subsidies for various "deserving" users, like lifeline telephone rates. They should be explicitly targeted, not general for everyone. Most of the issues being discussed have been faced and the consequences of alternative policies understood by corporate telecom managers. Some research into what has already been done in other settings would be very useful. Marvin Sirbu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050516033100> Received: from clash.cisco.com by SRI-NIC.ARPA with TCP; Thu, 5 May 88 23:05:31 PDT Received: from clash.cisco.com by clash.cisco.com with TCP; Thu, 5 May 88 23:03:33 PDT To: tcp-ip@sri-nic.arpa Subject: DDN X.25 Standard diagnostic codes Date: Thu, 05 May 88 23:03:31 PDT From: satz@clash.cisco.com Would someone be so kind as to forward me a copy of the latest DDN specific diagnostic codes? The codes I have are from the latest DDN specification circa 1983 and it seems newer codes are being returned in CLEAR REQUEST packets. Thanks! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2753@Shasta.STANFORD.EDU] <1988050518210500> From: paulf@Shasta.STANFORD.EDU (Paul A. Flaherty) Newsgroups: comp.protocols.tcp-ip Subject: att.com domain wierdness Message-ID: <2753@Shasta.STANFORD.EDU> Date: 5 May 88 18:21:05 GMT Organization: The Three Packeteers Lines: 9 Keywords: nameservers mail att I've noticed that the att.com MX entry keeps on drifting between att.arpa and rutgers.edu; can anyone give an explaination? -- -=Paul Flaherty, N9FZX | One Internet to rule them all, -- Tome Computer Systems Laboratory | One Internet to find them; of Stanford University | One Internet to bring them all, Internet ->paulf@shasta.Stanford.EDU | And in the Ether bind them. Hacking ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805072110.AA22760@ucbvax.Berkeley.EDU] <1988050522303200> From: EVANSL@VTVM1.BITNET (Lyle Evans) Newsgroups: comp.protocols.tcp-ip Subject: Federation of American Research Networks (FARnet) Message-ID: <8805072110.AA22760@ucbvax.Berkeley.EDU> Date: 5 May 88 22:30:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Sergio Heker writes > ... >As a point of information, there is a task force whithin the Federation >of American Research Networks (FARnet), working on this issue right now. Could somebody give me some more information about the Federation of American Research Networks FARnet ? Lyle Evans (Bitnet: Evansl @ VTVM1 ) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805061531.AA22148@ucbvax.Berkeley.EDU] <1988050601031100> From: M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA (Keith R. Hacke) Newsgroups: comp.protocols.tcp-ip Subject: Wollongong's TCP/IP Message-ID: <8805061531.AA22148@ucbvax.Berkeley.EDU> Date: 6 May 88 01:03:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 We are planning to purchase Wollongong's TCP/IP implementation for a MicroVAX running VMS. I am particularly interested in its use for Domain Name Serving between our Ethernet and the DDN (we have a Milnet connection). VMS is used on our VAXs, UNIX on the Suns and Silicon Graphics. What do you think of Wollongong's TCP/IP? Is anyone using it for Domain Name Serving? With a VAX running VMS? Other ideas (I know about using a Sun for the Domain Server)? Thanks Keith R. Hacke McDonnell Douglas 314-895-5343 PS Thanks to those who gave info on D. Comer's TCP/IP book. Our company library is getting it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [33974@felix.UUCP] <1988050601455100> From: zemon@felix.UUCP (Art Zemon) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together??? Message-ID: <33974@felix.UUCP> Date: 6 May 88 01:45:51 GMT References: <218@turbo.RAY.COM> Sender: daemon@felix.UUCP Reply-To: zemon@felix.UUCP (Art Zemon) Organization: FileNet Corp., Costa Mesa, CA Lines: 21 Keywords: TCP-IP. XNS. DECNET. Other people have given you the theoretical whys and wherefores about doing this. I thought I would chip in some practical experience in case you are the type who wants "real proof". (I'm not trying to be derogatory here, just helpful.) We run one Ethernet cable with the following protocols on it: TCP/IP XNS DECnet DEC LAT DEC MOP Everything runs just fine. Don't worry about it. -- -- Art Zemon By Computer: ...!hplabs!felix!zemon By Air: Archer N33565 By Golly: moderator of comp.unix.ultrix ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050604153300> Received: from SUVM.ACS.SYR.EDU by SRI-NIC.ARPA with TCP; Fri, 6 May 88 06:29:41 PDT Received: from SUVM.BITNET by SUVM.ACS.SYR.EDU ; Fri, 06 May 88 09:25:57 LCL Received: by SUVM (Mailer X1.25) id 2426; Fri, 06 May 88 09:25:56 LCL Date: Fri, 6 May 1988 09:15:33 LCL From: John M Wobus To: TCP-IP Discussion Group Subject: Discussion group on campus-sized networks. This is a reminder that there is an electronic-mail "list" or "discussion group" dedicated to campus-sized networks. I created it largely because I saw messages on the TCP-IP list that were really more about campus-sized networks than about TCP-IP and thought it would be nice to have a place where we wouldn't feel guilty discussing the stuff. You are welcome to join this list (which typically has about half the volume of TCP-IP). See the "blurb" below. John Wobus Syracuse University =------------------- BIG-LAN@SUVM.ACS.SYR.EDU (Internet) BIG-LAN@SUVM (Bitnet) This list is for the discussion of issues in designing and operating Campus-Size Local Area Networks, especially complex ones utilizing multiple technologies and supporting multiple protocols. Topics include repeaters, bridges, routers and gateways; how to incorporate smaller Personal-Computer type LANs into the campus-wide LAN; how to unify the mail systems, etc. This is an ideal list in which to debate the relative merits of bridges vs routers. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to BIG-REQ@SUVM.ACS.SYR.EDU (Internet) or BIG-REQ@SUVM (Bitnet). Those familiar with revised LISTSERV can subscribe with LISTSERV@SUVM.ACS.SYR.EDU (Internet) or LISTSERV@SUVM (Bitnet). Archives are available through revised LISTSERV. Coordinator: John Wobus ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805061247.AA18878@ucbvax.Berkeley.EDU] <1988050606033100> From: satz@CLASH.CISCO.COM Newsgroups: comp.protocols.tcp-ip Subject: DDN X.25 Standard diagnostic codes Message-ID: <8805061247.AA18878@ucbvax.Berkeley.EDU> Date: 6 May 88 06:03:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Would someone be so kind as to forward me a copy of the latest DDN specific diagnostic codes? The codes I have are from the latest DDN specification circa 1983 and it seems newer codes are being returned in CLEAR REQUEST packets. Thanks! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805061434.AA21039@ucbvax.Berkeley.EDU] <1988050614364100> From: JMWOBUS@SUVM.ACS.SYR.EDU (John M Wobus) Newsgroups: comp.protocols.tcp-ip Subject: Discussion group on campus-sized networks. Message-ID: <8805061434.AA21039@ucbvax.Berkeley.EDU> Date: 6 May 88 14:36:41 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 33 X-Unparsable-Date: Fri, 6 May 1988 09:15:33 LCL This is a reminder that there is an electronic-mail "list" or "discussion group" dedicated to campus-sized networks. I created it largely because I saw messages on the TCP-IP list that were really more about campus-sized networks than about TCP-IP and thought it would be nice to have a place where we wouldn't feel guilty discussing the stuff. You are welcome to join this list (which typically has about half the volume of TCP-IP). See the "blurb" below. John Wobus Syracuse University =------------------- BIG-LAN@SUVM.ACS.SYR.EDU (Internet) BIG-LAN@SUVM (Bitnet) This list is for the discussion of issues in designing and operating Campus-Size Local Area Networks, especially complex ones utilizing multiple technologies and supporting multiple protocols. Topics include repeaters, bridges, routers and gateways; how to incorporate smaller Personal-Computer type LANs into the campus-wide LAN; how to unify the mail systems, etc. This is an ideal list in which to debate the relative merits of bridges vs routers. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to BIG-REQ@SUVM.ACS.SYR.EDU (Internet) or BIG-REQ@SUVM (Bitnet). Those familiar with revised LISTSERV can subscribe with LISTSERV@SUVM.ACS.SYR.EDU (Internet) or LISTSERV@SUVM (Bitnet). Archives are available through revised LISTSERV. Coordinator: John Wobus ----MESSAGE-END---- ----MESSAGE-BEGIN---- [358@halley.UUCP] <1988050615335300> From: bc@halley.UUCP (Bill Crews) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <358@halley.UUCP> Date: 6 May 88 15:33:53 GMT References: <1607@erix.UUCP> Reply-To: bc@halley.UUCP (Bill Crews) Organization: Tandem Computers, Austin, TX Lines: 19 In article <1607@erix.UUCP> per@erix.ericsson.se (Per Hedeland) writes: > >Typically there are 5-10 clients in each group. There are currently some 20 >such groups, but predictions are for hundreds in the not too distant future, >i.e. considering other connected equipment, far more than 256 addresses are >required for the backbone. > It seems to be a terrible >waste of adress space to use a separate class C number for each of the client >groups, so we figured that subnetting would be appropriate, It does to me, too. So, why not just use class B addresses? Based on the criteria you dictate, that would seem to be adequate for now and the future. -bc -- Bill Crews Tandem Computers bc@halley.UUCP Austin, Texas ..!rutgers!im4u!halley!bc (512) 244-8350 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12396218063.60.LYNCH@A.ISI.EDU] <1988050619393400> From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Campus Network Query Message-ID: <12396218063.60.LYNCH@A.ISI.EDU> Date: 6 May 88 19:39:34 GMT References: <800@jimi.cs.unlv.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Greg, There is excellent brand new book on thart subject. It is called "Campus Networking Strategies", Caroline Arms, Editor. It is "sponsored" by EDUCOM, published by Digital Press, ISBN 1-55558-009-2, Order No. EY-6736E-DP. It is a collection of description sof the campus networks and how they came to be. All written by knowledgable people. The campuses included are: Wesleyan, Dartmouth, CMU, Rensselaer, MIT, Stanford, Cornell, Michigan, Minnesota and Penn State. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [18701@watmath.waterloo.edu] <1988050623491700> From: egisin@watmath.waterloo.edu (Eric Gisin) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together??? Message-ID: <18701@watmath.waterloo.edu> Date: 6 May 88 23:49:17 GMT References: <218@turbo.RAY.COM> <33974@felix.UUCP> Organization: U of Waterloo, Ontario Lines: 6 Keywords: TCP-IP. XNS. DECNET. One thing no-one has mentioned yet is the case where the ethernet type is a valid 802.3 packet length. I think Xerox PUP falls in to this catagory (what's PUP anyway?). What do 802.3 compatible systems do with such packets? VMS 4.4, for example, supports 802.3 LLC headers. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805062353.AA23117@mimsy.umd.edu] <1988050623531100> From: chris@MIMSY.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: A new record? Message-ID: <8805062353.AA23117@mimsy.umd.edu> Date: 6 May 88 23:53:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 PING okeeffe.berkeley.edu (128.32.130.3): 56 data bytes 64 bytes from 128.32.130.3: icmp_seq=11. time=253239. ms 64 bytes from 128.32.130.3: icmp_seq=294. time=1070. ms So where *was* that packet for four minutes and 13 seconds? (Maybe it was routed via the University of Mars :-) ) Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805070009.aa05227@Huey.UDEL.EDU] <1988050704093000> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Campus Network Query Message-ID: <8805070009.aa05227@Huey.UDEL.EDU> Date: 7 May 88 04:09:30 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 Dan, That sounds like a fantastically useful book. Do you have information on publisher or ISBN? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805071150.AA17422@devvax.TN.CORNELL.EDU] <1988050711500600> From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) Newsgroups: comp.protocols.tcp-ip Subject: Re: A new record? Message-ID: <8805071150.AA17422@devvax.TN.CORNELL.EDU> Date: 7 May 88 11:50:06 GMT References: <8805062353.AA23117@mimsy.umd.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 Chris: not a record, unfortunately. Dave Mills, at least, has one that returned after 16 minutes and something -- I'll bet there are even better ones. Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1988.05.07.07.24.09.milazzo.20101@titan.rice.edu] <1988050712240900> From: milazzo@RICE.EDU (Paul Milazzo) Newsgroups: comp.protocols.tcp-ip Subject: Re: A new record? Message-ID: <1988.05.07.07.24.09.milazzo.20101@titan.rice.edu> Date: 7 May 88 12:24:09 GMT References: <8805071150.AA17422@devvax.TN.CORNELL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Chris: I once ran ping for hours on a newly-installed proNet-10, with similarly frightening results. My host, a lightly-loaded VAX-11/750, was pinging itself because it was the only host on the ring. Amidst thousands of 20 msec round-trip times, one ping returned---out of sequence---after 11.5 seconds! Where could it have hidden for that long? I assume it was parked in an mbuf somewhere; a three-million kilometer detour seems unlikely... Paul G. Milazzo Dept. of Computer Science Rice University, Houston, TX ----MESSAGE-END---- ----MESSAGE-BEGIN---- [648@lakesys.UUCP] <1988050713175700> From: steven@lakesys.UUCP (Steven Goodman) Newsgroups: comp.protocols.tcp-ip Subject: 3.1 & Excelan Message-ID: <648@lakesys.UUCP> Date: 7 May 88 13:17:57 GMT Organization: Lake Systems, Milwaukee Wisconsin Lines: 31 Recently installed the Excellan TCP/IP software and 205T board in an AT&T 8386 box, running AT&T's UNIX System V Release 3.1. The Excellan software is 8014-01. The machines seem to be able to "talk" ok with the exception of some failures with "rcp", "ftp", and "rsh" (remsh). Now Excellan does not presently support 3.1 and I am looking for someone whom perhaps has this package presently running under 3.1. Actually with the exception of the above problems, the system appears to perform fairly well although I have not yet done any programing with this package, any exchange of information regarding this would be appreciated. The other machines are running the "WIN" TCP/IP on AT&T 3B15's and UNIX 2.1.2. Some of the failures are in having the WIN software talk to the Excellan, and could possibly be the resault of the new stuff in 3.1 ( ie; /etc/shadow ) although I have not yet spent alot of time examining this possibility. It's unfortunate that I have only one Excellan package running to examine if this is a problem resaulting in the 2.1.2 and 3.1 or WIN to Excellan. Might also mention that I would gladly assist anyone attempting this port as well to get you at least as far as we have. -- Steven M. Goodman Lake Systems - Milwaukee, Wisconsin {ihnp4,uwvax}!uwmcsd1!lakesys!steven {rutgers,uunet}!marque!/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3026964@um.cc.umich.edu] <1988050715115800> From: Doug_Nelson@UM.CC.UMICH.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <3026964@um.cc.umich.edu> Date: 7 May 88 15:11:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 In message <1607@erix.UUCP>, Per Hedeland writes: > a) It appears that the intended use of subnetting assumes that all the "subs" > of a "whole" net are interconnected, i.e. the backbone and the client > segments in our case should be "subs" of the same "whole" - in particular, > "automatic" routing by means of routed (which we desire) will not work > otherwise, as far as I can understand. Yes, that has to be true - you can only advertise your full network, not your subnets, to the Internet at large. > b) "Subs" of a given "whole" must be of equal size. This is a mistaken assumption. There is nothing that prevents you from using subnets of different sizes on a given net, except for software that isn't up to speed on subnetting (notably SunOS 3.x). For example, our campus-wide network is a class B sized subnet of a class A network. The Merit network itself is a class A/2 subnet, and Univ of Michigan has parceled out a number of class C-sized subnets. I plan to pass out class C-sized subnets of our network (or possibly smaller) to several other campus Ethernets, as soon as we get SunOS 4.0 installed. Doug Nelson den@serv1.cl.msu.edu Michigan State University 08071den@msu.bitnet Computer Laboratory ----MESSAGE-END---- ----MESSAGE-BEGIN---- [270@mahendo.Jpl.Nasa.Gov] <1988050802032700> From: earle@mahendo.Jpl.Nasa.Gov (Greg Earle) Newsgroups: comp.protocols.tcp-ip Subject: The ultimate solution to the packet chargeback problem Message-ID: <270@mahendo.Jpl.Nasa.Gov> Date: 8 May 88 02:03:27 GMT References: <93400005@uiucdcsp> <[A.ISI.EDU]29-Apr-88.18:15:38.CERF> Reply-To: earle@mahendo.JPL.NASA.GOV (Greg Earle) Organization: Sun Microsystems - Los Angeles Consulting Lines: 25 In article <[A.ISI.EDU]29-Apr-88.18:15:38.CERF> cerf@a.ISI.EDU writes: >The accounting issue comes up for two reasons: the MILNET operation folks >need to allocate costs among the users of MILNET and the general growth >of the Internet infrastructure can't be supported solely on government >subsidy in today's climate. I say add an extra MX missile or two to the military's budget request for each year, but instead funnel the money to AT&T et al. to pay for all the ARPANET & MILNET network links. That way we don't need chargeback, the government can subsidize it, and I'll feel just an epsilon better about where my tax dollars went. Without politicizing the argument, there is so much waste of government money in the military-industrial complex that I don't see how anyone in the government could complain about having to subsidize these networks, which are a sterling example of non-wasted monies buying such virtuousness :-) I mean, how many months of a 56 Kb line could be paid for with the price of an Air Force plane toilet seat? There. That was easy, now wasn't it? [ BTW: :-) ] -- Greg Earle earle@mahendo.JPL.NASA.GOV Indep. Sun consultant earle%mahendo@jpl-elroy.ARPA [aka:] (Gainfully Unemployed) earle%mahendo@elroy.JPL.NASA.GOV Lake View Terrace, CA ...!{cit-vax,ames}!elroy!jplgodo!mahendo!earle ----MESSAGE-END---- ----MESSAGE-BEGIN---- [233@laic.UUCP] <1988050804244800> From: wilson@laic.UUCP (Robin Wilson) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Message-ID: <233@laic.UUCP> Date: 8 May 88 04:24:48 GMT References: <218@turbo.RAY.COM> <14505@sgi.SGI.COM> Organization: Lockheed AI Center, Menlo Park Lines: 22 Keywords: TCP-IP. XNS. DECNET. Summary: It can be done. We have a very large network here at Lockheed. We have Ungermann/Bass terminal servers using XNS, and Vaxen using DECnet, SUNs using NFS and TCP, Symbolics using CHAOS (TCP derivative), and assundry "special" cases using there own brand of protocols. Our primary concern, in having them all use the same cable (baseband Ethernet bridged together with protocol independant VitaLink TransLAN Bridges), is coordinating additions of new devices of the SAME protocol. For example, I work at the Research Lab in Palo Alto, and we are bridged over a VitaLink to the main Lockheed facility in Sunnyvale; we are constantly having problems when the Sunnyvale people connect stuff up to their network and forget to tell us. One time, our DECnet crapped out because we were set to route to only 30 nodes. The Sunnyvale facility had connected a very extensive network to theirs using a VitaLink, the new network had about 40 DECnet nodes, and when they added them to our DECnet, our router began to swap between the thirty most recently seen nodes, and then trashed. The long and the long (no short story here) of it is that if you connect alot of different protocols to your network, be sure you keep tight reigns on the addition of new devices, some of them may have effects you never dreamed of on your other nodes out there. R.D. WILSON "Keep your grubby paws off of my views!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [477@dg2kk.rmi.de] <1988050816021400> From: wd@dg2kk.rmi.de (Walter Doerr) Newsgroups: comp.protocols.tcp-ip Subject: Info on TCP/IP book wanted Message-ID: <477@dg2kk.rmi.de> Date: 8 May 88 16:02:14 GMT Reply-To: wd@dg2kk.UUCP Organization: dg2kk, W Germany, (JO30FT) Lines: 7 Can anyone please tell me the price of Doug Comer's book about TCP/IP. I'd like to know because ordering US book here in Germany can be quite expensive. Thanks. Walter ----MESSAGE-END---- ----MESSAGE-BEGIN---- [854@kaos.UUCP] <1988050816442300> From: romkey@kaos.UUCP (John Romkey) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Chaosnet (Re: Many things on ethernet together???) Message-ID: <854@kaos.UUCP> Date: 8 May 88 16:44:23 GMT References: <218@turbo.RAY.COM> <14505@sgi.SGI.COM> <233@laic.UUCP> Reply-To: romkey@kaos.UUCP (John Romkey) Organization: Chaos; Somerville, MA Lines: 16 Keywords: TCP-IP. XNS. DECNET. In article <233@laic.UUCP> wilson@laic.UUCP (Robin Wilson) writes: >... Symbolics using CHAOS (TCP derivative)... Point of information: the Chaos protocols are not TCP-derivative. They were developed independently at the MIT AI Laboratory just before or at about the same time as TCP was first being worked on. The Chaosnet protocols were developed along with the Chaosnet hardware, which is pretty much gone today. They look a lot like TCP except that Chaos addresses are smaller, the reliable stream protocol is sequences blocks of data rather than bytes, and the "IP" and "TCP"-like parts of it are smooshed together, Chaos has 'contact names' rather than well known ports...well, the Chaos protocols bear some resemblance, anyway. -- - john romkey UUCP: romkey@kaos.uucp ARPA: romkey@xx.lcs.mit.edu ...harvard!spdcc!kaos!romkey Telephone: (617) 776-3121 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [203@tekbspa.UUCP] <1988050819125100> From: joe@tekbspa.UUCP (Joe Angelo) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <203@tekbspa.UUCP> Date: 8 May 88 19:12:51 GMT References: <358@halley.UUCP> Organization: Teknekron Software Systems, San Jose, CA. Lines: 23 in article <358@halley.UUCP>, bc@halley.UUCP (Bill Crews) says: > Xref: tekbspa comp.dcom.lans:150 comp.protocols.tcp-ip:495 > > > It does to me, too. So, why not just use class B addresses? Based on the > criteria you dictate, that would seem to be adequate for now and the future. > Now, the classes of IP addresses is simple enough to understand -- But what about subnetting? When does one want to *really* use two IP network address on the same cable? And what performance advantages does this give you? Were does the netmask come it at? Is subnetting just a nice admistrativia thing? Or does your local enet board not receive the packets, period? Or is it the high level software that ignores the packet? Does anything really ignore anything? -- "I'm trying Joe Angelo -- Senior Systems Engineer/Systems Manager to think at Teknekron Software Systems, Palo Alto 415-325-1025 but nothing happens!" uunet!tekbspa!joe -OR- tekbspa!joe@uunet.uu.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4512@orstcs.CS.ORST.EDU] <1988050821004500> From: ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff) Newsgroups: comp.protocols.tcp-ip Subject: Re: A new record? Message-ID: <4512@orstcs.CS.ORST.EDU> Date: 8 May 88 21:00:45 GMT References: <8805062353.AA23117@mimsy.umd.edu> Reply-To: ruffwork@CS.ORST.EDU (Ritchey Ruff) Organization: CS Dept, Oregon State University, Corvallis Lines: 17 In article <8805062353.AA23117@mimsy.umd.edu> chris@MIMSY.UMD.EDU (Chris Torek) writes: >PING okeeffe.berkeley.edu (128.32.130.3): 56 data bytes >64 bytes from 128.32.130.3: icmp_seq=11. time=253239. ms >64 bytes from 128.32.130.3: icmp_seq=294. time=1070. ms > >So where *was* that packet for four minutes and 13 seconds? >(Maybe it was routed via the University of Mars :-) ) > >Chris Well, in 253.239 seconds light can travel 75,971,700 klicks. Mars is (ruff-ly) around 120,000,000 klicks away right now, so it didn't get routed through the Protion gateway at U of Mars. My guess is that some VAX at a circular partical accellerator is going flakey and routed this ICMP into the partical beam path...round and round your data goes... --ritchey ruff ruffwork@cs.orst.edu -or- ...!hp-pcd!orstcs!ruffwork ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805090727.AA11410@uc.msc.umn.edu] <1988050907272200> From: slevy@UC.MSC.UMN.EDU ("Stuart Levy") Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <8805090727.AA11410@uc.msc.umn.edu> Date: 9 May 88 07:27:22 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 > > b) "Subs" of a given "whole" must be of equal size. > > This is a mistaken assumption. There is nothing that prevents you > from using subnets of different sizes on a given net, except for > software that isn't up to speed on subnetting (notably SunOS 3.x). Unfortunately, there -are- problems with dividing a network into variable-sized subnets -- not just incomplete software implementations but real engineering problems. They relate to cases where hosts or gateways need to know the size of a subnet they're not attached to: e.g. when interpreting an ICMP network redirect, synthesizing a remote broadcast address, or routing to a remote subnet. You may be able to live with the effects of misinterpretations if things are kept simple enough (so long as nothing sends you a network redirect :->). The subnetting RFCs, e.g. 917, 936, 950 discuss some possible conventions for determining subnet sizes, including equal sizes on a given network (easy) and self-encoding subnet sizes analogous to the class A/B/C sizing for ordinary networks. I suppose it would also be possible to distribute a table of subnet sizes to every host and gateway on a network. But in general, you -do- have to be able to know the sizes of sibling subnets, and the equal-size case seems to be the closest one to a standard. Stuart Levy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3752@cbmvax.UUCP] <1988050912110500> From: grr@cbmvax.UUCP (George Robbins) Newsgroups: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted Message-ID: <3752@cbmvax.UUCP> Date: 9 May 88 12:11:05 GMT References: <477@dg2kk.rmi.de> Reply-To: grr@cbmvax.UUCP (George Robbins) Organization: Commodore Technology, West Chester, PA Lines: 13 In article <477@dg2kk.rmi.de> wd@dg2kk.UUCP writes: > Can anyone please tell me the price of Doug Comer's book about TCP/IP. > I'd like to know because ordering US book here in Germany can be quite > expensive. I got my copy at Reiter's bookstore in Wash. DC for $36.00 - I assume this is the list price. I haven't read the whole thing yet, but it appears to be an excellent overview of the subject... -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988050913330000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Mon, 9 May 88 16:14:11 PDT Date: 9 May 88 18:33:00 EST From: Subject: TCP/IP for WANG devices? To: "tcp-ip" I am doing a report for a client within the Federal Government. Does anyone know of an implementation of TCP/IP for either the WANG Alliance Minicomputer or the WANG Wise Box? The configuration includes DOS terminals connected to the Alliance Minicomputer forming a star, and some Wise Boxes - All WANG equipment. I do not know the exact operating system version, and I have tried the TCP/IP vendors guide. Any help would be appreciated. Please send responses directly to me...I will post if anyone else is interested in this. Thanks Ron Wontrop Contel Federal Systems WONTROP@BLUTO.SCC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12@mace.cc.purdue.edu] <1988050915341500> From: dls@mace.cc.purdue.edu (David L Stevens) Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <12@mace.cc.purdue.edu> Date: 9 May 88 15:34:15 GMT References: <8805090727.AA11410@uc.msc.umn.edu> Reply-To: dls@mace.cc.purdue.edu.UUCP (David L Stevens) Organization: PUCC UNIX Group Lines: 14 Differing subnet sizes are not really a problem on all systems-- the "only if your software isn't up to snuff" comment applies. 4.3BSD includes enhancements to ICMP to ask for the interface's netmask ("ICMP_MASKREQ"). I don't know of any user-level program that uses this (yet). Also, I don't think it's been clear that the "variable size" subnets are by individual bits, not just bytes. You can split a class B net number into 17 bits of network and 15 bits of host, if that's what you really want to do. Some software only supports A subnetted to B and B subnetted to C (ie, by bytes), though. Void where prohibited. Your mileage may vary. Of course, if you have sources, you can fix it. -- +-DLS (dls@s.cc.purdue.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805091611.AA07124@braden.isi.edu] <1988050916114000> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <8805091611.AA07124@braden.isi.edu> Date: 9 May 88 16:11:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 45 > > b) "Subs" of a given "whole" must be of equal size. > > This is a mistaken assumption. There is nothing that prevents you > from using subnets of different sizes on a given net, except for > software that isn't up to speed on subnetting (notably SunOS 3.x). Unfortunately, there -are- problems with dividing a network into variable-sized subnets -- not just incomplete software implementations but real engineering problems. They relate to cases where hosts or gateways need to know the size of a subnet they're not attached to: e.g. when interpreting an ICMP network redirect, synthesizing a remote broadcast address, or routing to a remote subnet. Stuart, Let's consider the three examples you cite. Network Redirect: It is recognized that network redirects are a problem in a subnetted environment, and therefore the Gateway Specification RFC-1009 says that gateways should only be sending host redirects. If you have a gateway within your subnetted environment that is sending network redirects, it should be brought up to spec. Synthesizing a remote broadcast -- presumably you mean a directed broadcast. Yes, this is a real engineering problem, although it is an application-level problem, not an IP level problem. If you have an application that is sending directed broadcasts into another subnet of the same network, that application needs some configuration information -- obviously, it needs the remote subnet number. You might as well configure it with the complete 32-bit Internet directed broadcast address. Synthesizing IP addresses should be avoided whenever possible. Routing to a remote subnet -- This is entirely a gateway problem. The solution, as RFC-1009 suggests, is simply to include the subnet masks with the network numbers in the routing updates among the subnet gateways. I wonder why no one has extended RIP in this obvious way yet. As you say, it is merely a matter of a little engineering. After all this, I would challenge your statement that "in general, you -do- have to be able to know the sizes of sibling subnets" (at least, if "you" is a host, not a gateway). Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22485@bu-cs.BU.EDU] <1988050916154500> From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted Message-ID: <22485@bu-cs.BU.EDU> Date: 9 May 88 16:15:45 GMT References: <477@dg2kk.rmi.de> Organization: Boston U. Comp. Sci. Lines: 9 In-reply-to: wd@dg2kk.rmi.de's message of 8 May 88 16:02:14 GMT >Can anyone please tell me the price of Doug Comer's book about TCP/IP. >I'd like to know because ordering US book here in Germany can be quite >expensive. I don't see any list price on it, I bought it at Stacey's in Palo Alto, CA for $36.00. Beyond that you should probably call Prentice-Hall. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3030368@um.cc.umich.edu] <1988050916320800> From: Doug_Nelson@UM.CC.UMICH.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <3030368@um.cc.umich.edu> Date: 9 May 88 16:32:08 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 As a couple of you have pointed out, routing is the problem with multiple subnets of different sizes. We manage routing within our subnet very trivially - we don't really do routing, since we have only a single gateway to the outside world. I encourage our Sun owners to add a default route pointing to their own system, which adds a few ARPs to our local network, but finds the gateway just fine. What really is needed is a subnet routing protocol which passes netmasks along with the network numbers. Is anyone working on this yet? Can anyone tell me if 4.3bsd includes the netmask in each routing table entry? We need this to make such a protocol usable. Doug Nelson ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1073@thumper.bellcore.com] <1988050917211200> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: The ultimate solution to the packet chargeback problem Summary: Bureaucratic self-preservation Message-ID: <1073@thumper.bellcore.com> Date: 9 May 88 17:21:12 GMT References: <93400005@uiucdcsp> <[A.ISI.EDU]29-Apr-88.18:15:38.CERF> <270@mahendo.Jpl.Nasa.Gov> Organization: Bell Communications Research, Inc Lines: 15 > ... Without politicizing the argument, there is so much > waste of government money in the military-industrial complex that I don't > see how anyone in the government could complain about having to subsidize > these networks... You don't understand how bureaucrats work. When faced with a budget crunch, they do NOT respond by trimming the most wasteful expenditures first. Rather, they immediately zero in on the most visible, efficient, essential and popular programs, hoping that the resulting public backlash will pressure the legislators into restoring their original budget. This is a standard ploy at all levels of government. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805091745.AA24461@ACC-SB-UNIX.ARPA] <1988050917451900> From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) Newsgroups: comp.protocols.tcp-ip Subject: Honeywell and DG Message-ID: <8805091745.AA24461@ACC-SB-UNIX.ARPA> Date: 9 May 88 17:45:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Good morning all! I am going to be running Honeywell and Data General systems on a LAN soon and have been told by a customer that they have TCP/IP implement- ations running on them. Does anyone have any comments, suggestions, war stories or anything else that relates to these implementations? I have never been one for reinventing the wheel and would be very grateful for any input that could make this a bit easier. Thanks in advance, Chris VandenBerg ACC chris@acc-sb-unix.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [596@mtxinu.UUCP] <1988050918375500> From: ed@mtxinu.UUCP (Ed Gould) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <596@mtxinu.UUCP> Date: 9 May 88 18:37:55 GMT References: <358@halley.UUCP> <203@tekbspa.UUCP> Reply-To: ed@mtxinu.UUCP (Ed Gould) Organization: mt Xinu, Berkeley Lines: 48 >Now, the classes of IP addresses is simple enough to understand -- > >But what about subnetting? When does one want to *really* use >two IP network address on the same cable? And what performance >advantages does this give you? Were does the netmask come it at? The purpose of subnetting is not to run multiple IP addresses on the same cable, but to make a local collection of networks appear as if it were one network from the outside. To do this, one takes a standard IP adress (ususally a Class B address, but this isn't required) and uses some of the bits that are normally the "host number" part of the address as if they were part of the "network number." The netmask determines the division between host part and network part that is used locally. For example, consider the following /etc/hosts excerpt, which lists several Class B addresses. Keep in mind a netmask of 0xFFFFFF00 (the normal Class B netmask is 0xFFFF0000). 129.1.1.1 main-sys 129.1.2.1 main-sys-gw 129.1.2.2 second-sys 129.1.2.3 third-sys One topology this could represent is net to outside internal net (129.1.1) (129.1.2) ________ _________________________________ | | | | | | | | ----------- ------------- -------------- | | | | | | | main-sys| | second-sys| | third-sys | | | | | | | ----------- ------------- -------------- In this case, there are two physical networks: one connecting the three machines locally, and one connecting the main system to the outside world. To the outside world, the three machines look as if they are connected together on a single Class B network. Internally, though, they look as if they were on two separate Class C networks with a gateway. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,uunet}!mtxinu!ed +1 415 644 0146 "I'll fight them as a woman, not a lady. I'll fight them as an engineer." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880509134045.00000D78.AIKV.01@CDCCentr] <1988050918404500> From: PAYNE@CDCCENTR.BITNET (JAMES M. PAYNE (612) 482-2575 CDC ARH207) Newsgroups: comp.protocols.tcp-ip Subject: RIP Message-ID: <880509134045.00000D78.AIKV.01@CDCCentr> Date: 9 May 88 18:40:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 1 YES WE ARE CONSIDERING RIP. JIM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [588@bpa.BELL-ATL.COM] <1988050920260900> From: espo@bpa.BELL-ATL.COM (Bob Esposito) Newsgroups: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted Message-ID: <588@bpa.BELL-ATL.COM> Date: 9 May 88 20:26:09 GMT References: <477@dg2kk.rmi.de> Reply-To: espo@bpa.UUCP (Bob Esposito) Organization: Bell of Penna., Phila. Lines: 9 The price is $46.00 for Doug Comer's TCP/IP book. -- Bob Esposito, Bell of Pennsylvania uucp: {rutgers|cbmvax|bellcore}!bpa!espo A Bell Atlantic Company domain: espo@bpa.bell-atl.com Philadelphia, PA. phone: +1 215 466 6831 ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2962@ea.ecn.purdue.edu] <1988050922163400> From: mckay@ea.ecn.purdue.edu (Dwight D Mckay) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Message-ID: <2962@ea.ecn.purdue.edu> Date: 9 May 88 22:16:34 GMT References: <218@turbo.RAY.COM> <14505@sgi.SGI.COM> <233@laic.UUCP> Reply-To: mckay@ea.ecn.purdue.edu.UUCP (Dwight D Mckay) Organization: Purdue University Engineering Computer Network Lines: 9 Keywords: TCP-IP. XNS. DECNET. While we're on the topic: Is it possible to have Novell NetWare on the same wire with TCP/IP, XNS and AppleTalk (ethertalk?)? --Dwight Mckay, ECN Workstation Software Support [arpanet: mckay@ee.ecn.purdue.edu, usenet: ...ihnp4!pur-ee!mckay] [Compu-serve: 75776,1521, office: EE 348B, phone: (317) 494-3561] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805100755.AA14544@ucbvax.Berkeley.EDU] <1988050923330000> From: wontrop@BLUTO.SCC.COM Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP for WANG devices? Message-ID: <8805100755.AA14544@ucbvax.Berkeley.EDU> Date: 9 May 88 23:33:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 I am doing a report for a client within the Federal Government. Does anyone know of an implementation of TCP/IP for either the WANG Alliance Minicomputer or the WANG Wise Box? The configuration includes DOS terminals connected to the Alliance Minicomputer forming a star, and some Wise Boxes - All WANG equipment. I do not know the exact operating system version, and I have tried the TCP/IP vendors guide. Any help would be appreciated. Please send responses directly to me...I will post if anyone else is interested in this. Thanks Ron Wontrop Contel Federal Systems WONTROP@BLUTO.SCC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805100123.AA06235@uc.msc.umn.edu] <1988051001233900> From: slevy@UC.MSC.UMN.EDU ("Stuart Levy") Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <8805100123.AA06235@uc.msc.umn.edu> Date: 10 May 88 01:23:39 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 OK. If we have permission to squash systems sending subnet redirects it'll make the situation easier. (At the University of Minnesota we've had real operational problems with this in the past.) And when we do have routing protocols that carry explicit subnet masks I'll happily shut up. It'll still seem useful, though, OK, maybe not essential for hosts to be able to find the subnet structure of a net. For sending directed broadcasts, suppose you want to say "broadcast on the net where host X lives" where X is known by name. It might be desirable to use the normal mechanism for finding X's address rather than hard-wiring an IP address into an application. In that case, since the domain name system doesn't (and shouldn't) record network structure, how could you find the right broadcast address? Admittedly this may stretch the point a bit but not too far, I think. Likewise, if a host and several gateways are on some (sub)net, the host might want to set up its routing tables for a "good" choice of gateway to other subnets. Granting that routing should work if the host picks -some- gateway and depends on that to forward and/or redirect traffic as needed, it could still make good use of the information if it could get it. Again, routing protocols designed for variable-sized subnets would let this happen naturally. Stuart ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805100150.AA07641@braden.isi.edu] <1988051001503800> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <8805100150.AA07641@braden.isi.edu> Date: 10 May 88 01:50:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 It'll still seem useful, though, OK, maybe not essential for hosts to be able to find the subnet structure of a net. For sending directed broadcasts, suppose you want to say "broadcast on the net where host X lives" where X is known by name. It might be desirable to use the normal mechanism for finding X's address rather than hard-wiring an IP address into an application. In that case, since the domain name system doesn't (and shouldn't) record network structure, how could you find the right broadcast address? Admittedly this may stretch the point a bit but not too far, I think. Stuart, Directed broadcast is generally a poor idea (the right solution is the IP multicasting). No architectural decision should be taken on the grounds that it makes makes directed broadcasting easier. Likewise, if a host and several gateways are on some (sub)net, the host might want to set up its routing tables for a "good" choice of gateway to other subnets. Granting that routing should work if the host picks -some- gateway and depends on that to forward and/or redirect traffic as needed, it could still make good use of the information if it could get it. I disagree. The Internet standard approach for a host: pick any gateway and let it redirect you... is simple and effective. You REALLY DON'T want hosts to know about routing, even subnet routing!! Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [May.9.22.08.28.1988.8089@athos.rutgers.edu] <1988051002082900> From: lear@athos.rutgers.edu (eliot lear) Newsgroups: comp.protocols.tcp-ip Subject: Re: att.com domain wierdness Message-ID: Date: 10 May 88 02:08:29 GMT References: <2753@Shasta.STANFORD.EDU> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 5 Keywords: nameservers mail att To: paulf@Shasta.STANFORD.EDU Thank you for your note. The problem has been noted and corrective action has been taken on this end. -- Eliot Lear [lear@rutgers.edu] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805101325.AA15092@iapetus] <1988051013251300> From: almes@RICE.EDU (Guy Almes) Newsgroups: comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Message-ID: <8805101325.AA15092@iapetus> Date: 10 May 88 13:25:13 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 RD: The key point here is that ethernet is a ``local area network'' technology, and that its designers *never* intended it to be a wide area network. This is not to say that long-distance bridging is never the right thing to do, but only that you should not be surprised when it exhibits limits. This idea of `local' suggests, not only physically proximity, but also adminstrative unity. In your case, it wasn't the physical distance, but the administrative distance that caused the problems. If you stay with the single pseudo-ethernet bridged approach, then you will need to have admini- strative structures that treat it as a single ethernet. -- Guy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19880510142454.2.DCP@SWAN.SCRC.Symbolics.COM] <1988051014240000> From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Message-ID: <19880510142454.2.DCP@SWAN.SCRC.Symbolics.COM> Date: 10 May 88 14:24:00 GMT References: <233@laic.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Date: 8 May 88 04:24:48 GMT From: pyramid!leadsv!laic!wilson@decwrl.dec.com (Robin Wilson) False information alert! ... Symbolics using CHAOS (TCP derivative) ... Chaos is not a TCP derivative. Chaos was in active service at MIT around 1978 or so, which I think was before TCP became operational. Chaos is more a derivation of (Xerox) PUP and Arpanet NCP, with a bunch of things "fixed." In some ways it is more powerful than TCP/IP, and in some ways less. It is certainly not a derivative of TCP, even though Chaos's designers worked in the same building as some of the major contributors to the TCP design. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5422@megaron.arizona.edu] <1988051016511700> From: tsf@arizona.edu (Ted Frohling @ CCIT-Telcommunications, University of Arizona) Newsgroups: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted Message-ID: <5422@megaron.arizona.edu> Date: 10 May 88 16:51:17 GMT References: <477@dg2kk.rmi.de> Organization: U of Arizona CS Dept, Tucson Lines: 7 Summary: Price of Internetworking... by Douglas Comer The price for Douglas' book is $US 36.00. -- Ted Frohling Internet: tsf@rvax.ccit.arizona.edu Network Support BITNET: tsf@arizrvax.BITNET CCIT - Telecommunications AT&T: (602) 621-4834 University of Arizona, Tucson, AZ 85721 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805101659.AA16832@fiona50a.CCS.Northeastern.EDU] <1988051016591300> From: mckee@fiona50a.ccs (george mckee) Newsgroups: comp.protocols.tcp-ip Subject: controlling IP "type of service" Message-ID: <8805101659.AA16832@fiona50a.CCS.Northeastern.EDU> Date: 10 May 88 16:59:13 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Thinking about network pricing policies and accepting for the moment that relays don't grow on trees, I see on p.12 of RFC791 a description of a "Type of Service" field in an IP packet header that requests different levels of delay, throughput, and reliability, as well as specifying priorities ranging from "routine" through "flash override" and beyond. Do any of the popular implementations actually try to set this field, and does it affect the delivered performance of the network? (My Unix man page for ip(4P) says "other options are ignored".) - George McKee NU Computer Science ----MESSAGE-END---- ----MESSAGE-BEGIN---- [859@wright.EDU] <1988051017235600> From: jsloan@wright.EDU (John Sloan) Newsgroups: comp.protocols.tcp-ip,comp.sys.dec Subject: Plenum-Rated Ethernet Transceivers Keywords: plenum transceiver ethernet Message-ID: <859@wright.EDU> Date: 10 May 88 17:23:56 GMT Organization: Wright State University, Dayton OH, 45435 Lines: 28 I've seen references on the net to plenum-rated ethernet transceivers but have never read any specific citations. Plenum-rated transceivers could be used in the plenum, the environmental air space above drop ceilings (and other places). Plenum-rated transceiver and coax cable is common. I note that the standard DEC transceiver says on its label very specifically that it is NOT plenum rated, as do the BICC and 3COM transceivers we use. The Cabletron transceiver literature says "conforms to UL 910 and NEC 725-2(b) requirements for installation in air-handling spaces". A quick phone call to our rep had him reading this verbatum over the phone, which wasn't much help. Other phone calls have yielded similar results. A call to our University electrician, who is supposed to know at least the codes, was not of much use. So here I am wasting everyone's bandwidth. Does anyone have specific recommendations, including vendor name and part number? If anyone else is interested, I'll investigate it from there and summerize results. Thanks! -- John Sloan, The SPOTS Group Wright State University Research Building CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!cbosgd!wright!jsloan +1-513-259-1384 +1-513-873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [358@lalk.excelan.UUCP] <1988051017290400> From: chuck@excelan.UUCP (Chuck Kollars) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Keywords: TCP/IP XNS DECnet Appletalk Novell NetWare Message-ID: <358@lalk.excelan.UUCP> Date: 10 May 88 17:29:04 GMT References: <218@turbo.RAY.COM> <14505@sgi.SGI.COM> <233@laic.UUCP> <2962@ea.ecn.purdue.edu> Reply-To: chuck@lalk.UUCP (Chuck Kollars) Organization: Excelan Inc., San Jose, CA Lines: 20 In article <2962@ea.ecn.purdue.edu> mckay@ea.ecn.purdue.edu.UUCP (Dwight D Mckay) writes: >...Is it possible to have Novell NetWare on the same wire with TCP/IP, XNS and AppleTalk (ethertalk?)? Yes, all protocols can run on the same Ethernet wire at the same time. Novell's network OS can run over many different media, one of which is Ethernet. If you're using Ethernet with NetWare, consider attaching *all* the NetWare Servers and *all* the Workstations to one Ethernet cable. Multiple NetWare Servers on a single cable works fine. And the Workstations will have direct access not only to the NetWare Servers, but also to all the non-NetWare nodes if and when they need it. -- Chuck Kollars, Excelan, Inc. (chuck@excelan.UUCP) mabell: (408) 434-7434 Internet: mtxinu!excelan!chuck@ucbvax.Berkeley.COM telex: 176610 uucp: ...!{mtxinu,leadsv,cae780}!excelan!chuck fax: (408) 434-2310 post: Excelan, 2180 Fortune Drive, San Jose CA, 95131 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051018240000> Received: from CORNELLC.CCS.CORNELL.EDU by SRI-NIC.ARPA with TCP; Tue, 10 May 88 23:26:06 PDT Received: from SASK by CORNELLC.CCS.CORNELL.EDU ; Wed, 11 May 88 02:25:46 EDT Date: Wed, 11 May 88 00:24 CST From: Derek Andrew Subject: RE: Re: Many things on ethernet together??? To: TCP-IP@SRI-NIC.ARPA X-VMS-To: IN%"TCP-IP@SRI-NIC.ARPA",ANDREW We run many different protocols over the same Ethernet network. We have encountered one problem which is currently under study. We had these two 3COM labs for our students. Each lab has a file server. When both labs were added to the campus network, the servers would both compete for control over the workstations. That is, machines in one lab would try to log into the server in the other lab. The moral of the story is that it is not multiple protocols that will kill you, but rather networking companies like 3COM with limited vision as to the environments in which their products will be used. Note that we run XNS in the 3COM labs, not TCP/IP. Derek Andrew, Manager of Computer, Networking and Technical Services University of Saskatchewan andrew@sask on bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805102321.AA26819@hogg.cc.uoregon.edu] <1988051023211100> From: jqj@HOGG.CC.UOREGON.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <8805102321.AA26819@hogg.cc.uoregon.edu> Date: 10 May 88 23:21:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 > The Internet standard approach for a host: pick any >gateway and let it redirect you... is simple and effective. .... but works abysmally given the typical host software that allows you either to (1) set a static default route to the world, or (2) run passive RIP or something like it. If I choose option 1 and the default gateway crashes, it won't be around to send ICMP redirects telling me to use the backup gateway. Phrased differently, the "Internet standard" does not adequately address the issue of how a host should pick the first gateway to try. >You REALLY DON'T want hosts to know about routing. At issue here is a critical point: how smart is it desirable for hosts to be? Braden argues that they should be very dumb. I would argue that they can be dumb if they don't really need connectivity off their network, but should be a little bit smarter if possible. If you concede that, then the next step is to decide whether it is better for a host to have: (1) a static list (n>1) of gateways to try; (2) some as yet undefined dynamic discovery mechanism for a host on a network to find the list of gateways without getting routing data; (3) hosts that listen to routing traffic and hence could potentially use the data to avoid that first bad choice of a gateway. My personal bias: Passive RIP works just fine in the XNS world as a HOST protocol as well as as a gateway protocol. It works adequately in the IP world for typical CANs and moderately complex LANs. I see no real alternative available at present. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [380@cloud9.UUCP] <1988051100331200> From: bob@cloud9.UUCP (Bob Toxen) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together??? Summary: You can hang almost any protocol off the same cable Keywords: TCP-IP. XNS. DECNET. Message-ID: <380@cloud9.UUCP> Date: 11 May 88 00:33:12 GMT References: <218@turbo.RAY.COM> <33974@felix.UUCP> Organization: Stratus Computer, Inc., Marlboro, MA Lines: 11 You can run just about any protocl on the same ethernet cable. This is because anyone wanting to devise a new protocol is supposed to obtain a protocol number from Xerox. This protocol number is encoded in the sent packet. Receivers are expected to recognize only the protocols they are prepared to deal with. This is why this works. -- Bob Toxen {ucbvax!ihnp4,harvard,cloud9!es}!anvil!cavu!bob Stratus Computer, Marlboro, MA Pilot to Copilot: What's a mountain goat doing way up here in a cloud bank? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880510-175117-10169@Xerox] <1988051100510600> From: RMRichardson.PA@Xerox.COM (Rich) Newsgroups: comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Message-ID: <880510-175117-10169@Xerox> Date: 11 May 88 00:51:06 GMT References: <18701@watmath.waterloo.edu> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: RMRichardson.PA@Xerox.COM Organization: The Internet Lines: 16 From: clyde!watmath!egisin@bellcore.com (Eric Gisin) > One thing no-one has mentioned yet is the case where the ethernet type is > a valid 802.3 packet length. I think Xerox PUP falls in to this catagory > (what's PUP anyway?). PUP -- PARC Universal Packet PARC -- Palo Alto Research Center (Xerox) It means you can't talk PUP to hosts that act that way. One way around this is to change the PUP type numbers to outside the valid length range. This means all the PUP speakers on the net must all do this or you will have split the net into two types of PUP speakers who can talk to only their own type. The other is to hack the other guy (e.g., VMS) to figure out what is coming in. Rich ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23591@hi.unm.edu] <1988051103282000> From: cyrus@hi.unm.edu (Tait Cyrus) Newsgroups: comp.protocols.tcp-ip Subject: Question about LLC Message-ID: <23591@hi.unm.edu> Date: 11 May 88 03:28:20 GMT Organization: U. of New Mexico, Albuquerque Lines: 23 I hate to admit this, but I don't know diddly about the new 802 LLC frame format. Is there an RFC or some document on sri-nic that describes this format? If not, what texts contains such a description? The reason I ask is because devices on our net use the old dst/src/type format and now some of the newer devices are using the dst/src/len/llc and I can't make heads or tails of what these new devices are "saying". What is the `correct' way to refer to dst/src/type (IEEE 802.?) ? The `correct' way to refer to dst/src/len/llc (IEEE 802.3)? Thanks in advance. -- @__________@ W. Tait Cyrus (505) 277-0806 /| /| University of New Mexico / | / | Dept of Electrical & Computer Engineering @__|_______@ | Parallel Processing Research Group (PPRG) | | | | UNM/LANL Hypercube Project | | hc | | Albuquerque, New Mexico 87131 | @.......|..@ | / | / e-mail: @/_________@/ cyrus@hc.dspo.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805110351.AA05761@uc.msc.umn.edu] <1988051103514000> From: slevy@UC.MSC.UMN.EDU ("Stuart Levy") Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <8805110351.AA05761@uc.msc.umn.edu> Date: 11 May 88 03:51:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 It looks as though 4.3BSD subnetting code doesn't store a net mask per route. There's a net mask per -interface-, but it doesn't seem to be used the way you'd hope. There's effectively just one subnet mask per net for routing purposes (I think it uses the mask set by the first interface on the net) -- that is, 4.3BSD silently assumes equal-sized subnets on a given net. If I say ifconfig ex0 128.101.1.2 netmask 255.255.255.0 ifconfig ex1 128.101.27.27 netmask 255.255.240.0 the interface route for ex1 has a destination address of "128.101.16.0" (reasonable) BUT the route is only used when sending to 128.101.16.anything. Sending to 128.101.17.anything, ..., 128.101.31.anything does not increment the interface route's usage count. 4.3's multiple subnet masks are meaningful for interfaces on different nets but not for variable-sized subnets on a single net. It'll be interesting to see whether SUN 4.0 works the same way. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [100@vertical.oz] <1988051104191700> From: greg@vertical.oz (Greg Bond) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Keywords: TCP-IP. XNS. DECNET. Message-ID: <100@vertical.oz> Date: 11 May 88 04:19:17 GMT References: <218@turbo.RAY.COM> <14505@sgi.SGI.COM> <233@laic.UUCP> <2962@ea.ecn.purdue.edu> Reply-To: greg@vertical.oz (Greg Bond) Organization: Vertical Software, Melbourne, Australia Lines: 14 In article <2962@ea.ecn.purdue.edu> mckay@ea.ecn.purdue.edu.UUCP (Dwight D Mckay) writes: >Is it possible to have Novell NetWare on the same wire with TCP/IP, XNS and >AppleTalk (ethertalk?)? Certainly is. We have one thin enet cable here running SUNs (TCP/IP) and NetWare 2.0a concurrently. In fact, I have a PC that has a 3com enet card talking PC-NFS (TCP) and a Gateway G-net card talking Netware (on a separate cable!) at the same time. So if I had 2 enet cards I guess I could do both at once on the same cable from the same PC. -- Gregory Bond, Vertical Software, Melbourne, Australia Internet: greg@vertical.oz.au (or greg%vertical.oz.au@uunet.uu.net) UUCP: {uunet,pyramid,mnetor,ukc,ucb-vision}!munnari!vertical.oz!greg ACSnet: greg@vertical.oz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [20664@think.UUCP] <1988051104285900> From: barmar@think.COM (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Honeywell and DG Message-ID: <20664@think.UUCP> Date: 11 May 88 04:28:59 GMT References: <8805091745.AA24461@ACC-SB-UNIX.ARPA> Sender: usenet@think.UUCP Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge, MA Lines: 17 In article <8805091745.AA24461@ACC-SB-UNIX.ARPA> chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) writes: >Good morning all! > I am going to be running Honeywell and Data General systems on a >LAN soon and have been told by a customer that they have TCP/IP implement- >ations running on them. I don't know about DG, but I know that Honeywell Bull has several completely unrelated operating systems, running on almost as many different hardware architectures: GCOS-8, Multics, GCOS-6, and HVS1 to name a few (there's another I know of, but can't think of the name). Which one are you talking about? Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [May.11.00.29.12.1988.19766@athos.rutgers.edu] <1988051104291500> From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: A new record? Message-ID: Date: 11 May 88 04:29:15 GMT References: <8805062353.AA23117@mimsy.umd.edu> <4512@orstcs.CS.ORST.EDU> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 11 To: chris@mimsy.umd.edu In article <8805062353.AA23117@mimsy.umd.edu> chris@MIMSY.UMD.EDU (Chris Torek) writes: >PING okeeffe.berkeley.edu (128.32.130.3): 56 data bytes >64 bytes from 128.32.130.3: icmp_seq=11. time=253239. ms >64 bytes from 128.32.130.3: icmp_seq=294. time=1070. ms > >So where *was* that packet for four minutes and 13 seconds? Presumably in various gateway queues. However you might also check your ping to make sure it handles timing correctly when lots of packets are being dropped. One could imagine a bug that would cause it to report a time for the wrong one. This has happened to TCP implementations, as I'm sure you know. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051105460500> Received: from ccd.bbn.com by SRI-NIC.ARPA with TCP; Wed, 11 May 88 06:49:10 PDT Date: Wed, 11 May 88 09:46:05 EDT From: "Drew M. Powles" Subject: Who's got the time? To: tcp-ip@sri-nic.arpa Cc: dpowles@ccd.bbn.com Can someone please tell me which protocol is the most widely accepted for synchronizing Network Time? What work is being done in this area? What do most vendors implement? Is it RFC 958? Is there a later version? Thanks in advance for any and all information. Drew Powles BBN Communications dpowles@bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805120023.AA23762@ucbvax.Berkeley.EDU] <1988051106240000> From: ANDREW@SASK.BITNET (Derek Andrew) Newsgroups: comp.protocols.tcp-ip Subject: RE: Re: Many things on ethernet together??? Message-ID: <8805120023.AA23762@ucbvax.Berkeley.EDU> Date: 11 May 88 06:24:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 We run many different protocols over the same Ethernet network. We have encountered one problem which is currently under study. We had these two 3COM labs for our students. Each lab has a file server. When both labs were added to the campus network, the servers would both compete for control over the workstations. That is, machines in one lab would try to log into the server in the other lab. The moral of the story is that it is not multiple protocols that will kill you, but rather networking companies like 3COM with limited vision as to the environments in which their products will be used. Note that we run XNS in the 3COM labs, not TCP/IP. Derek Andrew, Manager of Computer, Networking and Technical Services University of Saskatchewan andrew@sask on bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [630@cgch.UUCP] <1988051109521800> From: whna@cgcha.uucp (Heinz Naef) Newsgroups: comp.protocols.tcp-ip,comp.protocols.ibm,comp.sources.wanted,eunet.general Subject: TCP/IP-to-SNA File Transfer Gateway Keywords: TCP/IP, FTP, BFTP, SNA, 3270-PC, ECF, SRPI, ibmftp. Message-ID: <630@cgch.UUCP> Date: 11 May 88 09:52:18 GMT Sender: news@cgch.UUCP Lines: 38 We are planning to implement a TCP/IP-to-SNA file transfer gateway to be used as a central service to provide file transfer capabilities between our TCP/IP network and some IBM MVS mainframes hanging off an SNA network. Our evaluation resulted in a concept based on an application level gateway, where the application is the most commonly used file transfer mechanism at each side of the gateway: - At the TCP/IP side, it is, of course, the File Transfer Protocol (FTP). - At the SNA side, we are thinking of an implementation based on the Enhanced Connectivity Facility (ECF) File Copy function. As a first step, we are planning to implement the requester (client) function of the IBM 3270 PC File Transfer Program. Please remember the following requirements: - The service only needs to ASYMMETRIC, where the IBM SNA side plays the passive role. - The service *has to* be INTERACTIVE because of security systems at the IBM hosts. - Development of software for the IBM hosts *must be* avoided. Only the gateway -- which could be an IBM -- can incorporate new software. With the proposed solutions, development of server entities for the IBM hosts can be avoided, since there are IBM program products available for both major operating systems, MVS and VM. Furthermore, possible requirements for a batch file transfer capability can be met by adding the Batch File Transfer Program (BFTP) - upon its availability - to the TCP/IP side of the gateway. Did anyone attempt or even complete an implementation of such a gateway? Please reply by mail, I will summarize your comments within a month or so. Thanks in advance, and best regards, Heinz Naef, c/o CIBA-GEIGY AG, R-1032.5.62, P.O.Box, CH-4002 Basel uucp: whna@cgch.uucp - bitnet: whna%cgch.uucp@cernvax.bitnet phone: (+41) 61 37 26 75 fax: (+41) 61 36 43 54 (Attn: H.Naef, R-1032.5.62) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805111501.AA02933@uunet.UU.NET] <1988051112290700> From: mo@maximo.UUCP (Mike O'Dell) Newsgroups: comp.protocols.tcp-ip Subject: Comer's book Message-ID: <8805111501.AA02933@uunet.UU.NET> Date: 11 May 88 12:29:07 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Price correction: $36.00 At least, that's what I paid for it at Jim Joyce's UNIX Bookstore. For another $6 you get it UPS Blue. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805120342.AA27414@ucbvax.Berkeley.EDU] <1988051113460500> From: dpowles@CCD.BBN.COM ("Drew M. Powles") Newsgroups: comp.protocols.tcp-ip Subject: Who's got the time? Message-ID: <8805120342.AA27414@ucbvax.Berkeley.EDU> Date: 11 May 88 13:46:05 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Can someone please tell me which protocol is the most widely accepted for synchronizing Network Time? What work is being done in this area? What do most vendors implement? Is it RFC 958? Is there a later version? Thanks in advance for any and all information. Drew Powles BBN Communications dpowles@bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805111426.AA08376@percival.cs.purdue.edu] <1988051114264200> From: narten@PURDUE.EDU (Thomas Narten) Newsgroups: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted Message-ID: <8805111426.AA08376@percival.cs.purdue.edu> Date: 11 May 88 14:26:42 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Typos and comments concerning Doug Comer's TCP/IP book can be sent to: tcp-typos@cs.purdue.edu or {ucbvax,decvax,ihnp4}!purdue!tcp-typos This is not a mail list, so please do not ask to join; it serves as a collection point for funnelling comments back to the author. Sorry, no points given for noting the mistake on the front cover. Thomas Narten ----MESSAGE-END---- ----MESSAGE-BEGIN---- [552@viscous] <1988051117082200> From: stewarta@sco.COM (Stewart I. Alpert) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Keywords: TCP-IP. XNS. DECNET. Message-ID: <552@viscous> Date: 11 May 88 17:08:22 GMT References: <218@turbo.RAY.COM> <14505@sgi.SGI.COM> <233@laic.UUCP> <2962@ea.ecn.purdue.edu> Reply-To: stewarta@sco.COM (Stewart I. Alpert) Organization: The Santa Cruz Operation, Inc. Lines: 8 In article <2962@ea.ecn.purdue.edu> mckay@ea.ecn.purdue.edu.UUCP (Dwight D Mckay) writes: > >While we're on the topic: > >Is it possible to have Novell NetWare on the same wire with TCP/IP, XNS and >AppleTalk (ethertalk?)? > Yes ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1919@ssc-vax.UUCP] <1988051117412200> From: bruce@ssc-vax.UUCP (Bruce Stock) Newsgroups: comp.protocols.tcp-ip Subject: 802 (.2).3 TCP/IP Keywords: interoperability? Message-ID: <1919@ssc-vax.UUCP> Date: 11 May 88 17:41:22 GMT Distribution: na Organization: Boeing Aerospace Corp., Seattle WA Lines: 20 Does anyone have any wisdom to share regarding the ability of TCP/IP versions based on Ethernet 2 frame formats to communicate with 802 (.2).3 based versions ( on the same network)? I just got a flyer for the Wollongong WIN/H3000 software (FTP, Telnet, SMTP) for the HP 3000 series of computers. This package uses the underlying 802 (.2).3 frame formats of HP's TCP/IP implementation for its lower layers. Most ( all?) other TCP implementations seem to use the Ethernet 2 frame formats and would probably not communicate with this package. Any experience to relate? It would seem that HP's TCP/IP implementation is grossly out of step with prevailing practice in the TCP arena. Are there any reasons to choose it, based on either short term or long term considerations? Bruce E. Stock Boeing Aerospace uw-beaver!ssc-vax!bruce ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12397546524.36.VAF@Score.Stanford.EDU] <1988051121170200> From: VAF@SCORE.STANFORD.EDU (Vince Fuller) Newsgroups: comp.protocols.tcp-ip Subject: Password transmission and encryption query Message-ID: <12397546524.36.VAF@Score.Stanford.EDU> Date: 11 May 88 21:17:02 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Recently, some people here have begun to grumble about the insecurities of having user passwords transmitted in the clear during TELNET sessions, FTP transfers, etc. I was wondering what solutions other places have devised to deal with this problem. I'd appreciate any information that TCP-IP readers have and any pointers to more information. Vince Fuller, Stanford Networking Systems ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805112228.AA28127@hogg.cc.uoregon.edu] <1988051122281500> From: jqj@HOGG.CC.UOREGON.EDU Newsgroups: comp.protocols.tcp-ip Subject: another TCP/IP book Message-ID: <8805112228.AA28127@hogg.cc.uoregon.edu> Date: 11 May 88 22:28:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 There has been much recent discussion of Comer's new INTERNETWORKING WITH TCP/IP on this list. My librarian tells me that there is another similar book, AN INTRODUCTION TO TCP/IP, by John Davidson. It was published by Springer-Verlag this year. It provides "an overview of TCP/IP. Contents: introduction, data link layer, network layer, transport layer, session through application layers." Has anyone seen the latter book? How does it compare with the Comer book? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051123255100> Received: from Xerox.COM by SRI-NIC.ARPA with TCP; Thu, 12 May 88 06:26:18 PDT Received: from Riesling.ms by ArpaGateway.ms ; 12 MAY 88 06:26:15 PDT Sender: "Thomas_D._Herbst.HENR801c"@Xerox.COM Date: 12 May 88 06:25:51 PDT (Thursday) Subject: Re:another TCP/IP book From: "Thomas_D._Herbst.HENR801c"@Xerox.COM To: tcp-ip@sri-nic.Arpa cc: jqj@hogg.cc.uoregon.EDU Message-ID: <880512-062615-2863@Xerox> >Date: Wed, 11 May 88 15:28:15 PDT >From: jqj@hogg.cc.uoregon.edu >Subject: another TCP/IP book > >There has been much recent discussion of Comer's new INTERNETWORKING >WITH TCP/IP on this list. My librarian tells me that there is another >similar book, AN INTRODUCTION TO TCP/IP, by John Davidson. It was >published by Springer-Verlag this year. It provides "an overview of >TCP/IP. Contents: introduction, data link layer, network layer, >transport layer, session through application layers." Has anyone seen >the latter book? How does it compare with the Comer book? I was rather disappointed with the Davidson book. While it does provide an introduction, it doesn't cover very much material in the depth that I require. It is a useful book for people that don't have to implement anything, say a manager trying to answer the question "What is this TCP/IP stuff, anyway?". I am anxiously awaiting my special ordered copy of Comer's book. tom ----MESSAGE-END---- ----MESSAGE-BEGIN---- [178@cbw1.UUCP] <1988051123494000> From: brian@cbw1.UUCP (Brian Cuthie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted Message-ID: <178@cbw1.UUCP> Date: 11 May 88 23:49:40 GMT References: <477@dg2kk.rmi.de> Reply-To: brian@cbw1.UMD.EDU (Brian Cuthie) Organization: CBW, Columbia, MD 21046 Lines: 18 In article <477@dg2kk.rmi.de> wd@dg2kk.UUCP writes: >Can anyone please tell me the price of Doug Comer's book about TCP/IP. >I'd like to know because ordering US book here in Germany can be quite >expensive. It's $36.00. It is a very good book. Ties alot of things together that would never be apparent from the RFCs. The nice thing is that he didn't try to replace the RFC's, but rather gives an overview of the internet and the protocols while refering to the RFCs for details. -brian -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [179@cbw1.UUCP] <1988051123523200> From: brian@cbw1.UUCP (Brian Cuthie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted Message-ID: <179@cbw1.UUCP> Date: 11 May 88 23:52:32 GMT References: <477@dg2kk.rmi.de> <588@bpa.BELL-ATL.COM> Reply-To: brian@cbw1.UMD.EDU (Brian Cuthie) Organization: CBW, Columbia, MD 21046 Lines: 15 In article <588@bpa.BELL-ATL.COM> espo@bpa.UUCP (Bob Esposito) writes: > > The price is $46.00 for Doug Comer's TCP/IP book. ^^^^^^ No wonder my phone service is so expensive. Do you bell guys get such a deal on everything ?? :-) -brian -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [864@kaos.UUCP] <1988051201010000> From: romkey@kaos.UUCP (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: Dumb vs. smart host routing Message-ID: <864@kaos.UUCP> Date: 12 May 88 01:01:00 GMT References: <8805102321.AA26819@hogg.cc.uoregon.edu> Reply-To: romkey@kaos.UUCP (John Romkey) Organization: Chaos; Somerville, MA Lines: 52 In article <8805102321.AA26819@hogg.cc.uoregon.edu> jqj@HOGG.CC.UOREGON.EDU writes: >>You REALLY DON'T want hosts to know about routing. >At issue here is a critical point: how smart is it desirable for hosts >to be? Braden argues that they should be very dumb. I would argue >that they can be dumb if they don't really need connectivity off their >network, but should be a little bit smarter if possible. As the network grows the part which will give out is the routing substrate. The Internet has already had this happen a few times. We went from GGP to EGP, then EGP broke and it had to support multiple packet updates, and now we're in the process of scrapping EGP for the next step. Each of these steps was good enough for networks of a certain size and broke as the network grew. If we can keep the hosts as stupid as possible with regard to the routing algorithms and bottle the complexity up in the routers then we're in a better position to deal with the next time the Internet hits a level where the existing routing protocols break. Whatever the next solution is, it may not hold for 10,000 networks. Or 100,000 networks. With one or two hundred hosts per network. [I've been working with TCP/IP long enough that when I started, we called routers 'gateways', so know that I'm using them as synonyms in this message.] I'd rather treat the network as a black box from the host's point of view. For a host with a single network interface, I think the best way for it to route is to have a list of default gateways which it cycles through, caching a route with a 'connection'. If TCP notices problems with lots of retransmissions, it could call IP and request that it reroute the connection (IP flushes the route and uses a different default gateway). Since the gateways know the TRUTH they can send ICMP redirects when they believe there is a better route. If some new protocols were cooked up to allow hosts to query routers for some useful information WITHOUT the hosts understanding how the routers worked, that would be okay as far as I'm concerned. Multihomed hosts are a more substantial problem, and right now they probably do have to at least listen to routing protocols in order to figure out the best routes to use. This way, the next time the routing substrate breaks because the Internetwork has grown too much, only the routing substrate needs to be changed. Just fixing this will be a bad enough problem without having to change all the host software in the world. We'll have a lot more flexibility to change the routing substrate then. -- - john romkey UUCP: romkey@kaos.uucp ARPA: romkey@xx.lcs.mit.edu ...harvard!spdcc!kaos!romkey Telephone: (617) 776-3121 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MWWEBgy00UoJE5z9YE@andrew.cmu.edu] <1988051201441200> From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) Newsgroups: comp.protocols.tcp-ip Subject: Re: Question about LLC Message-ID: Date: 12 May 88 01:44:12 GMT References: <23591@hi.unm.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 Check out RFC1042. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805120329.AA08290@vax.ftp.com] <1988051203293600> From: jbvb@VAX.FTP.COM (James Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: Question about LLC (802.2 packet formats) Message-ID: <8805120329.AA08290@vax.ftp.com> Date: 12 May 88 03:29:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 RFC1042 documents the official method for encapsulating IP (with a 'SNAP' header) in 802.2 packets. For complete information on 802.2 LLC, as the IEE envisioned it, I think you need to get the 802.2 standard itself from the IEEE. I always refer to them as "802.3" and "Bluebook" (from the DEC-Intel-Xerox "Blue Book" which was the original Ethernet standard). Some other people refer to them as "Ethernet" and "802.3", but I feel that is confusing to the neophyte. (It is kind of rough on someone who has just read his first "LANs are Great" article when you say "Ethernet and 802.3 really are different, trust me...".) jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1076@thumper.bellcore.com] <1988051204211400> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: controlling IP "type of service" Summary: Packet radio interpretation of TOS Message-ID: <1076@thumper.bellcore.com> Date: 12 May 88 04:21:14 GMT References: <8805101659.AA16832@fiona50a.CCS.Northeastern.EDU> Organization: Bell Communications Research, Inc Lines: 27 > Do any of the popular implementations actually try to set this > field, [TOS] and does it affect the delivered performance of the network? Mine (the KA9Q package) does. My IP interprets the "delay" and "reliability" bits in the AX.25 (amateur packet radio) subnet driver as follows: 1. If the "low delay" bit is set, send the datagram in an unnumbered information (UI) frame. There is no link level flow control or acknowledgment on these frames. 2. Else if the reliability flag is set, send the datagram as one (or more) regular information (I) frames, opening a new link connection if necessary. I frames are acknowledged and flow controlled at the link layer according to LAPB (the protocol on which AX.25 is based). The "or more" part refers to the possible use of subnet fragmentation and reassembly to keep the physical frames small without imposing an unreasonably small MTU on the IP layer. 3. Else use the interface's default encapsulation mode. Although the driver does look at these bits, this is just a hook for future use. At present my applications do not give the user the ability to control these bits in generated datagrams. The default mode is presently used for all datagrams. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1307@ntmtka.UUCP] <1988051212471700> From: andy prokop@ntmtka.UUCP (andy prokop) Newsgroups: comp.protocols.tcp-ip Subject: Public domain telnet/ftp Message-ID: <1307@ntmtka.UUCP> Date: 12 May 88 12:47:17 GMT Organization: Northern Telecom Inc., Minnetonka,MN Lines: 11 Posted: Thu May 12 07:47:17 1988 I have been asked by an acquaintance from another company (without access to Usenet) to find out if there are public domain versions of Telnet and FTP for Unix. Actually, they have a Unix look-alike (no ATT code), but that shouldn't matter. He wants source code, but I believe object might also do if he knew exactly what the program expected from the OS and runtime environment. Replies can either be posted or emailed directly to me. Thanks. | Andrew Prokop ems!ntmtka!andy | | Northern Telecom, Inc. | | 9705 Data Park (612) 932-8758 | | Minnetonka, MN 55343 | ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1604@hubcap.UUCP] <1988051213254300> From: hubcap@hubcap.UUCP (Mike Marshall) Newsgroups: comp.protocols.tcp-ip Subject: Doug Comer's TCP/IP book... Keywords: Stallings, Mockapetris, McLeod and Michel Message-ID: <1604@hubcap.UUCP> Date: 12 May 88 13:25:43 GMT Organization: Clemson University, Clemson, SC Lines: 15 I can't comment on Doug Comer's TCP/IP book, but I can suggest another book that I know to be very good... "Handbook of Computer Communications Standards, VOL 3" which deals with the DOD protocol standards. The book's authors lend it credibility, for example, Paul Mockapetris also wrote several RFC's including "Domain Names - Concept and Facilities". After having to turn to the book for reference several times, I have decided to buy the other two books in the series... [1] OSI model & related standards [2] Local Network standards Has anyone read both Comer's book and HCCS VOL-3? Any comments? -Mike Marshall hubcap@hubcap.clemson.edu ...!hubcap!hubcap ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805121045.aa05610@Huey.UDEL.EDU] <1988051214452400> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: controlling IP "type of service" Message-ID: <8805121045.aa05610@Huey.UDEL.EDU> Date: 12 May 88 14:45:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Yes, although some question may remain on your "popular" qualifier. The present NSFNET Backbone gateways (Fuzzballs) do interpret the TOS and Precedence fields and order the queues accordingly. So far as I know, no other implementation, including the new NSFNET Backbone gateways (IBM), interpret those fields, with the possible exception of the SATNET/WIDEBAND gateways (LSI-11/Butterfly), which at one time mapped the TOS field to specialized services available in these packet-satellite nets. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10285@ulysses.homer.nj.att.com] <1988051215365200> From: smb@ulysses.homer.nj.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <10285@ulysses.homer.nj.att.com> Date: 12 May 88 15:36:52 GMT References: <8805102321.AA26819@hogg.cc.uoregon.edu> <864@kaos.UUCP> Organization: AT&T Bell Laboratories, Murray Hill Lines: 37 One problem I see is that ICMP Redirect is largely useless. It's only useful for the first gateway along the way to tell the originating host to use a different gateway; it can't be used to tell an intermediate gateway what the proper next hop is. That is, assume we have a large LAN behind a single gateway G to the Internet. If a host H on that LAN wants to talk to host H' on another LAN behind another gateway G', all H can do is send the packets to G. G must know that G' is the proper next hop; if it chooses to use G'' instead, G'' cannot send an ICMP Redirect. Or rather, it can, but the Redirect will go to H, which can't do anything but send to G no matter what it receives. G'' doesn't know that the packet came from G, and hence can't advise G of the proper route. (To be sure, RFC1009 says that gateways within an autonomous system can use Redirects among themselves, but that's not a standardized use for the Internet.) The conclusion of all this is that local gateways must be extremely smart. The current scheme, with EGP, works well enough in the current environment, where there's one central net (ARPANET+MILNET); it would fail miserably if there were a large number of interconnected backbone nets. I'm not certain what to do about the problem. If Record Route were used more, or Loose Source route, a host could handle such a redirect more intelligently. (Of course, under the current spec it wouldn't be sent.) Perhaps we need a new option, ``Last Hop''; it would tell each gateway the immediate predecessor gateway to be advised of a routing correction. Then we'd need some new sort of Redirect message, possibly one that includes a loose source route, rather than just a simple gateway address. The combination of these might even allow a very smart gateway to straighten out twisty paths, though I'm not sure that that's feasible. And the security implications of enhanced Redirects needs to be considered very carefully. --Steve Bellovin ulysses!smb smb@ulysses.att.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805122325.AA06668@ucbvax.Berkeley.EDU] <1988051215534900> From: jon@CS.UCL.AC.UK.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Survey of TCP/IP Management Tools Message-ID: <8805122325.AA06668@ucbvax.Berkeley.EDU> Date: 12 May 88 15:53:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 57 Posted: Thu May 12 11:53:49 1988 I am conducting a survey of tools available for TCP/IP internetwork management that are in the public domain, or distributable freely, if with notice or whatever. I may include a list of some of the sorts of non-public domain tools that exist for comparison (e.g. some BSD handy things like rdist etc). I will collate answers and forward to this list when a reasonable set is accumulated. So far, the kind of tools I am thinking of fall loosely into three categories: A: Configuration management: e.g. UCL have a (n)awk based account management tool, that generates accounts, password files, mail aliases , nfs mount table parameters and so on. Programs for allocating addresses and names safely, would fall into this category. Programs for checking routing set ups for consistency might also go here. Domain name test suites might go here too. Programs for gathering traffic matrices fall into this category - and some network dimensioning tools might be handy (help answer where do i cut my ethernet type questions). B: Fault Detection: e.g. We have a version of ping that is driven by knowledge of the topology, (but does not use source route or record, unfortunately) and can therefore track where a link is down in a path. This is combined with a telnet level ping, to say what the state of any host is at the end of a path...it has a termcap driven graphic display... C: Performance management: e.g. tcpdump type programs that allow non-intrusive sensible analysis of protocols as they operate. e.g. traffic generators for UDP/TCP etc Note that I am interested mainly in collecting small tools that may be plugged together in a nice fashion rather than monolithic be all and end all systems, and I am biased towards simple existing network solutions - programs that depend on the more sophisticated features in gateways or hosts are no use, since all heterogeneous networks are lowest common denominator by defn. I would prefer not to restrict the list to Unix based tools, though I know shareware tends to come from that domain more than others. if answers could be of the form it would help: A/B/C name OS description Anon-FTP? Restrictions ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805121610.AA00251@bel.isi.edu] <1988051216105800> From: postel@VENERA.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: re: Question about LLC Message-ID: <8805121610.AA00251@bel.isi.edu> Date: 12 May 88 16:10:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 Posted: Thu May 12 12:10:58 1988 W. Tait Cyrus: Try looking at RFC-1042 for some clues. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880512092448.2260d215@Csa4.LBL.Gov] <1988051216244800> From: forrest@LBL.GOV Newsgroups: comp.protocols.tcp-ip Subject: Davidson's book vs. Comer's book Message-ID: <880512092448.2260d215@Csa4.LBL.Gov> Date: 12 May 88 16:24:48 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 I recently read both books, starting off as a complete novice. As I recall, the introduction to Davidson's book states that the book used to be a document that was distributed to marketing and sales people so that they'd have some idea what all the buzz words mean (my interpretation). With this as a goal the book is OK. But, I wanted a more in depth study of TCP/IP which is why I turned to Comer's book. Comer's book is MUCH better although some of the chapters (specifically those dealing with routing) didn't feel right. This is probably my fault and I intend to reread the whole book a second time. For the time being, Comer's book is the only entry in the race for the perfect TCP/IP book. Anyone new to TCP/IP, or anyone who wants to fill in holes in their knowledge would benefit greatly from reading it. I know I did. By the way, on page 40, the second high order bit on a class C address is shown incorrectly in Figure 4.1 (this was pointed out to me by someone else). I've submitted this type to the tcp-typos account. Jon Forrest Lawrence Berkeley Lab. FORREST@LBL.GOV ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805121238.aa06832@Huey.UDEL.EDU] <1988051216383300> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Who's got the time? Message-ID: <8805121238.aa06832@Huey.UDEL.EDU> Date: 12 May 88 16:38:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 41 Drew, First, let me point out that I am far from an unbiased source. Probably the most widely implemented time protocol is UDP/TIME, which is distributed with vanilla Unix. The 4.3bsd Unix distributions include a time daemon which manages time distribution within a LAN, but would not be suitable for use over most multi-net Internet paths. The Network Time Protocol (NTP) described in RFC-958, as amended, was specifically intended for time distribution both within a LAN and as far as the Internet eye can see. A 4.3bsd daemon for NTP is available from MIke Petry (petry@trantor.umd.edu). There are varying opinions on the robustness and accuracy of various time-synchronization mechanisms in the literature. The NTP design was based on models used by digital common carriers and uses maximum-likelihood estimation and nonlinear-filtering techniques. A survey of different approaches to the problem, the factors the led to the NTP design choices and a comprehensive bibliography on the subject can be found in the ~ftp/pub/ntp.doc file in the anonymous directory at louie.udel.edu. This document has been printed as a departmental report and submitted as an RFC. In my opinion it does not make sense to porpose a new service without extensive experimentation and evaluation of a prototype implementation. NTP was born three years ago and has been in regular use since that time with at least three radio-synchronized time servers (now with five). As the result of this experience the original NTP design was thoroughly overhauled and tested over the last six months. The resulting NTP design, including algorithms necessary to improve accuracy and mitigate between possibly broken or bogus clocks (falsetickers), is described in the cited document. All five of the radio-synchronized NTP servers, as well as all Fuzzball secondary servers (e.g. NSFNET Backbone gateways) and many Unix secondary/retail servers now tick the new version. In most places where such things can be measured, the service provides time acccurate to within a few tens of milliseconds and has an incredible degree of redundancy. Dave P.S. Truechimers may wish to subscribe to the list ntp@trantor.umd.edu for additional information. DLM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805121656.AA28839@hogg.cc.uoregon.edu] <1988051216565200> From: jqj@hogg.cc.uoregon.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <8805121656.AA28839@hogg.cc.uoregon.edu> Date: 12 May 88 16:56:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 John, I sympathize, and agree that yours is a defendable position. One problem with it is that it doesn't work if the local network is extremely dynamic, with lots of routers coming and going. An "ad absurdum" extension to your argument is that a host shouldn't have to have ARP; it should be able to make do with some static tables -- of course, that would be ridiculous since the list of hosts on the local network is much too dynamic to make such a table reasonable (though note that some implementations, e.g. SunOS 3.x diskless bootstrap, required just such a table). Similarly, I claim that we will need some sort of discovery mechanism if the list of gateways on a local network is expected to be large and dynamic. We have such a discovery mechanism in place today; passive RIP. I'm not recommending that we improve it, or that hosts use it for anything except finding the first gateway. Note that if in fact most host implementations already supported a list of default gateways then I'd be willing to live with that as an alternative. Unfortunately, they don't; most implementations give you exactly ONE default, which is not enough when that gateway crashes and stops sending ICMP redirects. >fixing this will be a bad enough problem without having to change all >the host software in the world I believe that a gateway can be taught to send out RIP packets saying "I'm a default router" without sending out any other data. If so, this would provide my desired discovery mechanism with no changes to a common flavor of host software (i.e. BSD derivatives). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051218334900> Received: from Cs.Ucl.AC.UK (purple.cs.ucl.ac.uk) by SRI-NIC.ARPA with TCP; Thu, 12 May 88 09:00:46 PDT Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK via Ethernet with SMTP id aa03089; 12 May 88 16:51 BST To: tcp-ip@sri-nic.arpa Subject: Survey of TCP/IP Management Tools Date: Thu, 12 May 88 16:53:49 +0100 From: Jon Crowcroft I am conducting a survey of tools available for TCP/IP internetwork management that are in the public domain, or distributable freely, if with notice or whatever. I may include a list of some of the sorts of non-public domain tools that exist for comparison (e.g. some BSD handy things like rdist etc). I will collate answers and forward to this list when a reasonable set is accumulated. So far, the kind of tools I am thinking of fall loosely into three categories: A: Configuration management: e.g. UCL have a (n)awk based account management tool, that generates accounts, password files, mail aliases , nfs mount table parameters and so on. Programs for allocating addresses and names safely, would fall into this category. Programs for checking routing set ups for consistency might also go here. Domain name test suites might go here too. Programs for gathering traffic matrices fall into this category - and some network dimensioning tools might be handy (help answer where do i cut my ethernet type questions). B: Fault Detection: e.g. We have a version of ping that is driven by knowledge of the topology, (but does not use source route or record, unfortunately) and can therefore track where a link is down in a path. This is combined with a telnet level ping, to say what the state of any host is at the end of a path...it has a termcap driven graphic display... C: Performance management: e.g. tcpdump type programs that allow non-intrusive sensible analysis of protocols as they operate. e.g. traffic generators for UDP/TCP etc Note that I am interested mainly in collecting small tools that may be plugged together in a nice fashion rather than monolithic be all and end all systems, and I am biased towards simple existing network solutions - programs that depend on the more sophisticated features in gateways or hosts are no use, since all heterogeneous networks are lowest common denominator by defn. I would prefer not to restrict the list to Unix based tools, though I know shareware tends to come from that domain more than others. if answers could be of the form it would help: A/B/C name OS description Anon-FTP? Restrictions ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12397779745.14.ROMKEY@XX.LCS.MIT.EDU] <1988051218380900> From: ROMKEY@XX.LCS.MIT.EDU (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <12397779745.14.ROMKEY@XX.LCS.MIT.EDU> Date: 12 May 88 18:38:09 GMT References: <8805121656.AA28839@hogg.cc.uoregon.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 47 >One problem with it is that it doesn't work if the local network is >extremely dynamic, with lots of routers coming and going. I envision networks where links to other networks come and go, but not the actual routers themselves. It's a strange idea to me. I don't see any application for it off the top of my head. >An "ad absurdum" extension to your argument is that a host shouldn't have to >have ARP; No, I think there's a big difference between the two examples. I don't want the hosts to have complete lists of all the routers on their network. Just a list of a few - the default routers. Many systems nowadays have an idea of one default router; I'd like to increase it to an arbitrary list of them which is cycled through for reliability. If you have only one default router then you lose big when it goes down. Since the routers all talk to one another, they know the best routes and if the default router chosen for a particular connection isn't the best, it will send an ICMP redirect and the host should change its route. It occurs to me that we're agreeing to some extent, but arguing over details. I don't care too much how the host discovers what its default routers are. Could be statically configured (though this isn't too good), BOOTP or some new broadcast ICMP message. I think that the details that we're disagreeing over are: 1. How many routers the host knows about. I want it to only have to know about a few. I don't really care how many, I'd like it to be more than one. At least nothing should depend on it knowing about them all. It doesn't bother me if the host does or doesn't know them all; ICMP will clean up the mess. I'm not sure that we're really disagreeing over this one... 2. How it discovers them. I'm very opposed to the host discovering routes by using routing protocols that the routers use internally. Having part of the routers' protocol be an interface to hosts which says "I'm a default router" or "This is a list of default routers for this subnet" is okay, as long as the host implementations don't sticky their fingers by prying open the routing protocols any more than that. If there's some way to do it without a broadcast protocol, or with one that minimizes the number of broadcasts, that would be a good thing. - john ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805121843.AA25506@TOTO.MIT.EDU] <1988051218431900> From: mar@ATHENA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: Password transmission and encryption query Message-ID: <8805121843.AA25506@TOTO.MIT.EDU> Date: 12 May 88 18:43:19 GMT References: <12397546524.36.VAF@Score.Stanford.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 The kerberos authentication system can help solve this problem. When both hosts in a transaction are using kerberos, it is never necessary to send passwords across the network. For remote login, we have already modified Berkeley Unix rlogin to use kerberos. A kerberos solution could be written for other operating systems as well. The documents describing the protocol are available via anonymous FTP from athena-dist.mit.edu (at 18.71.0.38). The code is currently in beta test (we've been using a version at MIT for over a year now), and will be released at some point in the future. If you cannot use FTP or want more information, you may send a request to info-kerberos@athena.mit.edu. -Mark Rosenstein ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10286@ulysses.homer.nj.att.com] <1988051219251600> From: smb@ulysses.homer.nj.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip Subject: Re: another TCP/IP book Message-ID: <10286@ulysses.homer.nj.att.com> Date: 12 May 88 19:25:16 GMT References: <8805112228.AA28127@hogg.cc.uoregon.edu> Organization: AT&T Bell Laboratories, Murray Hill Lines: 4 There's no comparison; the Davidson book is a fairly cursory overview (though probably still valuable to a novice), while Comer treats stuff in depth. Davidson's introduction describes the book as essentially a set of lecture notes; that's a fairly accurate description. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805122012.AA13251@brillig.umd.edu] <1988051220123400> From: pete@BRILLIG.UMD.EDU (Pete Cottrell) Newsgroups: comp.protocols.tcp-ip Subject: Re: Honeywell and DG Message-ID: <8805122012.AA13251@brillig.umd.edu> Date: 12 May 88 20:12:34 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 In article <8805091745.AA24461@ACC-SB-UNIX.ARPA> chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) writes: >Good morning all! > I am going to be running Honeywell and Data General systems on a >LAN soon and have been told by a customer that they have TCP/IP implement- >ations running on them. At one point we had an MV10000 running beta releases of DG's UN*X (DG/UX) implementation (SYSV-based). We were at level 3.0, I believe. They included a TCP/IP implementation and also included the Berkeley r-commands, as well as NFS. It seemed to work, although it seemed as though the ethernet board would veg out every once in a while. Since the machine was never really heavily used, and we had no source for the beast, we never really dug into the problem. Towards the end of its stay here, we went to 3.1 level of DG/UX and soon after got rid of it for a variety of reasons. This was about a year ago. I can't really vouch for how things stand now, I'm just speaking up to confirm that yes, there is a TCP/IP implementation for Data General machines, available from them, at least under DG/UX. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5276@sdcrdcf.UUCP] <1988051220240000> From: darrelj@sdcrdcf.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Message-ID: <5276@sdcrdcf.UUCP> Date: 12 May 88 20:24:00 GMT References: <18701@watmath.waterloo.edu> <880510-175117-10169@Xerox> Reply-To: darrelj@sdcrdcf.UUCP (Darrel VanBuer) Organization: Unisys - System Development Group, Santa Monica Lines: 26 Posted: Thu May 12 16:24:00 1988 In article <880510-175117-10169@Xerox> RMRichardson.PA@Xerox.COM writes: >> One thing no-one has mentioned yet is the case where the ethernet type is >> a valid 802.3 packet length. I think Xerox PUP falls in to this catagory >PUP -- PARC Universal Packet >It means you can't talk PUP to hosts that act that way. One way around >this is to change the PUP type numbers to outside the valid length range. >This means all the PUP speakers on the net must all do this or you will >have split the net into two types of PUP speakers who can talk to only It turns out PUP (and its companion address translation-private ARP type) are the only protocol numbers which conflict with 802.3 length. The new type numbers for 802.3 compatibility are 2048 (decimal) higher than they were, i.e. PUP is 2560(dec) or 0x0a00 PUP ARP is 2561(dec). PUP has endured past its experimental days because of an installed base of hardware which have come to depend on its services. One of the features of most PUP protocols which is both a benefit and a drawback is a slight blurring of the line between layers (in the interest of bit efficiency to ensure most useful interchanges fit a single 576 byte MTU packet). -- Darrel J. Van Buer, PhD; unisys; 2400 Colorado Ave; Santa Monica, CA 90406 (213)829-7511 x5449 KI6VY darrel@CAM.UNISYS.COM or ...{allegra,burdvax,cbosgd,hplabs,ihnp4}!sdcrdcf!darrelj ----MESSAGE-END---- ----MESSAGE-BEGIN---- [696@applix.UUCP] <1988051220590800> From: mark@applix.UUCP (Mark Fox) Newsgroups: comp.protocols.tcp-ip,comp.sys.dec Subject: Re: Plenum-Rated Ethernet Transceivers Summary: Use smoke detectors in the plenums Keywords: plenum transceiver ethernet Message-ID: <696@applix.UUCP> Date: 12 May 88 20:59:08 GMT References: <859@wright.EDU> Reply-To: mark@applix.UUCP (Mark Fox) Organization: APPLiX Inc., Westboro MA Lines: 19 In article <859@wright.EDU> jsloan@wright.EDU (John Sloan) writes: >I've seen references on the net to plenum-rated ethernet transceivers [etc.] > >...Does anyone have specific recommendations... When we first installed our Ethernet cable above our dropped ceiling we also had trouble getting info from fire & building officials. However, we were assured (not sure by whom -- it was 4+ years ago) that it was ok from a legal standpoint to install normal yellow PVC cable in plenums as long as smoke detectors were also present (in the plenums). It certainly is cheaper than installing Teflon cable or using metal conduit (at least in the absence of fire!) Anybody know if this is true today? Any specific building/fire code references available? Thanks. -- Mark Fox Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300 uucp: {ames,rutgers}!harvard!m2c!applix!mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1263@ucsfcca.ucsf.edu] <1988051222015200> From: dick@ccb.ucsf.edu.UUCP Newsgroups: comp.protocols.tcp-ip Subject: DACU wanted (used) Summary: for backup of existing DACU Message-ID: <1263@ucsfcca.ucsf.edu> Date: 12 May 88 22:01:52 GMT Sender: root@cca.ucsf.edu Reply-To: dick@cca.ucsf.edu (Dick Karpinski) Organization: UCSF Computer Center Lines: 17 Posted: Thu May 12 18:01:52 1988 The Computer Center at UCSF would like to buy a second IBM 7170-DACU to back up the existing box. Perhaps later we will be able to choose an effective replacement with better throughput and lower overhead. For now, we wish to feel secure that our Ethernet access is reliable. If you have replaced your DACU, we would like to know what you chose and why you chose it. Please let us know if you would be willing to part with the DACU, and under what terms. Please respond by mail or call me at (415) 476-4529 or Ian Tuller at (415) 476-5097. Thanks, Dick Dick Karpinski Manager of Minicomputer Services, UCSF Computer Center UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 476-4529 (11-7) BITNET: dick@ucsfcca or dick@ucsfvm Compuserve: 70215,1277 USPS: U-76 UCSF, San Francisco, CA 94143-0704 Telemail: RKarpinski Domain: dick@cca.ucsf.edu Home (415) 658-6803 Ans 658-3797 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805122330.AA06278@beast.DDN.MIL] <1988051223304100> From: stjohns@beast.DDN.MIL (Mike St. Johns) Newsgroups: comp.protocols.tcp-ip Subject: controlling IP "type of service" Message-ID: <8805122330.AA06278@beast.DDN.MIL> Date: 12 May 88 23:30:41 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 Dave, by TOS, do you also mean the precedence bits? Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [682@tetra.NOSC.MIL] <1988051300461800> From: budden@tetra.NOSC.MIL (Rex A. Buddenberg) Newsgroups: comp.protocols.tcp-ip Subject: Re: Password transmission and encryption query Message-ID: <682@tetra.NOSC.MIL> Date: 13 May 88 00:46:18 GMT References: <12397546524.36.VAF@Score.Stanford.EDU> Reply-To: budden@tetra.nosc.mil.UUCP (Rex A. Buddenberg) Organization: Naval Ocean Systems Center, San Diego Lines: 31 Vince, You might be interested in the way Defense Data Network will be handling a similar problem. Classified users will employ end-to- end encryption to protect their data. This is in addition to any link (aka bulk) encryption of the links. Each classified user is blessed with a gadget called a Blacker front-end device (KOI-111). If you and Ivan want to hold a session over the net, you compare keys on connection-open to see if you can talk at the required level of classification. If you can't, your host fires off a message to the authentication host (somewhere 'out there') who validates your clearance level and need to know. Assuming you are OK to conduct this session, the authentication node sends an enabling message to the key control host (also 'out there') who then proceeds to issue keys to you and Ivan and off you go. When you are done, the keys can be made to evaporate (consider all the crypto custodian grunt labor and insecurity this gets rid of). I believe the key distribution process makes use of the RSA algorithms, but not sure. There are other complementary parts of this larger system. The trusted computer security standards for this will be top-drawer, (A1 in Orange-book-ese). Also the classified portion of DDN will be segregated from the unclas side (and all the rest of us out in net-land) probably forever. Rex Buddenberg USCG Headquarters ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805122125.aa12572@Huey.UDEL.EDU] <1988051301250500> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: controlling IP "type of service" Message-ID: <8805122125.aa12572@Huey.UDEL.EDU> Date: 13 May 88 01:25:05 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Mike, You're gonna love this: The queues are ordered by precedence; however, in case of TCP and either the source or destination port fields are TELNET, then assume a precedence of one. E pluribum unicorn and pass the rsh sauce, please. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805122131.aa12584@Huey.UDEL.EDU] <1988051301311500> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: controlling IP "type of service" Message-ID: <8805122131.aa12584@Huey.UDEL.EDU> Date: 13 May 88 01:31:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Mike, I lied and even misrepresented my own code. The queues are ordered by the value of the entire 8-bit TOS octet, including both precedence and DTR bits. In case of TCP and either source or destination port fields are TELNET, behave as if the D (delay) bit is set. Note the precedence bits are at the high-order end, so my previous message is morally right but factually inaccurate. What the heck, close enough for academic work. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051302562500> Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by SRI-NIC.ARPA with TCP; Fri, 13 May 88 06:43:10 PDT To: tcp-ip@sri-nic.ARPA Subject: Third TCP-IP Book? Date: Fri, 13 May 88 09:36:25 -0400 From: Craig Partridge IEEE Computer has an ad by Springer-Verlag which beyond listing Davidson's book, also mentions The Complete Guide to TCP/IP Protocol Suite by Don Huntington and George Cohn due out in 1988. I don't know either author and they aren't in the NIC table. Anyone heard anything about this book? Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [599@riddle.UUCP] <1988051304583000> From: andrew@riddle.UUCP (Andrew Beattie) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Competition for Bridge Keywords: TCP-IP. Bridge. Message-ID: <599@riddle.UUCP> Date: 13 May 88 04:58:30 GMT Reply-To: andrew@riddle.UUCP (Andrew Beattie) Organization: Sphinx Ltd., Maidenhead, England Lines: 14 Does anyone other than Bridge make Ethernet TCP/IP Terminal servers? (A bit of healthy competition might help their price policy :-) ) Mail me, and I'll post a summary. Many thanks. Andrew Beattie Sphinx, 43-53 Moorbrige Road, Maidenhead, England mcvax!ukc!reading!riddle!andrew andrew@sphinx.co.uk +44 628 75343 #include ----MESSAGE-END---- ----MESSAGE-BEGIN---- [93400006@uiucdcsp] <1988051305110000> From: zweig@uiucdcsp.cs.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Password transmission and encryptio Message-ID: <93400006@uiucdcsp> Date: 13 May 88 05:11:00 GMT References: <36@<12397546524> Lines: 15 Nf-ID: #R:<12397546524:36:uiucdcsp:93400006:000:647 Nf-From: uiucdcsp.cs.uiuc.edu!zweig May 13 00:11:00 1988 The best and most common solution I know of is to have ``boring'' accounts that accept anonymous FTP (witness sri-nic et al.) so nobody cares who listens in to passwords. :-) If it's worth protecting, it's worth hiding from rlogin's and ftp and that sort of thing, isn't it? Johnny Zweig University of Illinois at Urbana-Champaign Department of Computer Science --------------------------------Disclaimer:------------------------------------ Rule 1: Don't believe everything you read. Rule 2: Don't believe anything you read. Rule 3: There is no Rule 3. ------------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051306101600> Received: from MITVMA.MIT.EDU by SRI-NIC.ARPA with TCP; Fri, 13 May 88 07:52:45 PDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 8188; Fri, 13 May 88 10:29:18 EDT Received: by MITVMA (Mailer X1.25) id 8186; Fri, 13 May 88 10:29:17 EDT Date: Fri, 13 May 88 10:10:16 EDT From: KASTEN@MITVMA.MIT.EDU Subject: Re: Dumb vs. smart host routing To: jqj@hogg.cc.uoregon.edu In-Reply-To: Your message of Thu, 12 May 88 09:56:52 PDT Cc: tcp-ip@sri-nic.arpa > Similarly, I claim that we will need some sort of discovery mechanism >if the list of gateways on a local network is expected to be large and >dynamic. We have such a discovery mechanism in place today; passive >RIP. I'm not recommending that we improve it, or that hosts use it for >anything except finding the first gateway. UNfortunately, not all of the systems that use IP are (easily) capable of running a RIP listener. PC's are the best example - they do not have multitasking, making it difficult to load in a program to listen to the RIP traffic. There are ways of doing it but this is not a forum for discussing PC stuff. >I believe that a gateway can be taught to send out RIP packets saying >"I'm a default router" without sending out any other data. If so, this >would provide my desired discovery mechanism with no changes to a >common flavor of host software (i.e. BSD derivatives). Not all of us are so lucky as to have a BSD system available on which we can build our stuff. I like the idea of the "I am a Router" broadcast's. The problem, again, is that not all hosts may be capable of listening at all times for that broadcast (even a BSD machine could be turned off). Instead, a query and response type of protocol could be used. When a host needs to send something off net and either A) does not have the IP Address of any router (if it had one address, it could send a packet to that router and get the redirect) or B) the host decides that the router it is using is dead (e.g. TCP has retransmitted too often) then the host broadcast a "Who can route to network X?" request and the routers on the local network would respond. This would require changes to both routers and hosts, but I think is the most flexible over the widest range of hosts - from the single "tasked" PC's up to Crays. Of course, you still can listen to RIP (but what if the routers want to use another protocol?) Frank Kastenholz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [874@kaos.UUCP] <1988051306225400> From: romkey@kaos.UUCP (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <874@kaos.UUCP> Date: 13 May 88 06:22:54 GMT References: <8805102321.AA26819@hogg.cc.uoregon.edu> <864@kaos.UUCP> <10285@ulysses.homer.nj.att.com> Reply-To: romkey@kaos.UUCP (John Romkey) Organization: Chaos; Somerville, MA Lines: 48 In article <10285@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven Bellovin) writes: >One problem I see is that ICMP Redirect is largely useless. It's only >useful for the first gateway along the way to tell the originating host >to use a different gateway; it can't be used to tell an intermediate >gateway what the proper next hop is. But that's not really a problem with ICMP redirects at all. Look at it this way: ICMP redirects are the (okay, *a*) way routers communicate routing information to hosts XYZ (fill in your favorite routing protocol(s)) is the way routers communicate routing information to one another. If the routers are doing their job properly then the routers on the same subnet as the host will redirect it to the proper router via ICMP; this router will then do XYZ things to figure out how to route the packet from there. It's because of XYZ that the routers know when to redirect in the first place. >The conclusion of all this is that local gateways must be extremely >smart. The current scheme, with EGP, works well enough in the current >environment, where there's one central net (ARPANET+MILNET); it would >fail miserably if there were a large number of interconnected backbone >nets. > >I'm not certain what to do about the problem. The example assumes that the routers are screwed up in the first place. You don't necessarily have to have an incredible amount of information in your routers that are used by your host - you just have to have routing protocols that do the right thing (which may actually require incredible amounts of information...oh well). The thing to do about it is to refine the XYZ protocols (ancient GGP, RIP, EGP) so that they work better for larger, more complicated networks. Yes, the current system doesn't deal with complicated networks very well. It doesn't handle redundant routes well. It doesn't handle load-sharing very well. It doesn't route on Type of Service very well (because not a lot of routers support it and virtually no hosts set the TOS field in the IP header). I believe there are people on an IETF task force or working group or some such working on this problem. -- - john romkey UUCP: romkey@kaos.uucp ARPA: romkey@xx.lcs.mit.edu ...harvard!spdcc!kaos!romkey Telephone: (617) 776-3121 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051308564800> Received: from MITVMA.MIT.EDU by SRI-NIC.ARPA with TCP; Fri, 13 May 88 10:02:50 PDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0459; Fri, 13 May 88 13:00:09 EDT Received: by MITVMA (Mailer X1.25) id 0456; Fri, 13 May 88 13:00:08 EDT Date: Fri, 13 May 88 12:56:48 EDT From: Frank Kastenholz Subject: Re: Doug Comer's TCP/IP book... To: Mike Marshall In-Reply-To: Your message of 12 May 88 13:25:43 GMT Cc: tcp-ip@sri-nic.arpa I read HCCS Vol 3 (By William Stallings - ISBN 0-02-948072-8, MacMillan) and found it to be a good "My First TCP Book" for some technical type of person who is trying to get into the game. It is too much for the non-techie. Haven't read Comer's book yet. Frank Kastenholz ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051309190000> Received: from nrl-lcp.arpa by SRI-NIC.ARPA with TCP; Fri, 13 May 88 10:21:00 PDT Date: 13 May 88 13:19:00 EDT From: Subject: TCP-IP Book of the Month Club To: "tcp-ip" cc: yurcik Reply-To: I also recommend Doug Comer's book. Free enterprise seems to be at its best by giving the network people what they want and creating what I believe will be a major new topic area in the technical book market. I have become aware of another book, "The Complete Guide to TCP/IP" by Don Huntingdon & George Cohn soon to be released by Springer-Verlag, NYC, NY. Can anybody comment on its content? Are the authors out there? Any others thinking about becoming an author? Bill Yurcik "yurcik@nrl-lcp.arpa" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051311593000> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Fri, 13 May 88 14:46:08 PDT Received: from en-c06.prime.com by RELAY.CS.NET id aa00533; 13 May 88 16:10 EDT Received: from CSP-A.Prime.COM by EN-C06.Prime.COM; 13 May 88 16:07:37 EDT Received: (from user MIKEC) by CSP-A.Prime.COM; 13 May 88 15:59:30 EDT To: TCP-IP@SRI-NIC.ARPA From: MIKEC%csp-a.prime.com@RELAY.CS.NET Date: 13 May 88 15:59:30 EDT To: (smb@ulysses.att.com) Cc: (tcp-ip@sri-nic.arpa) From: Michael A. Curtis (mikec@csp-a.prime.com) Date: 13 May 88 3:40 PM Subject: Re: Smart vs. dumb host routing Steve, I think you've missed the whole point of the issue. That is the exact intent of ICMP in this case. Once the host delivers the packet, its job is over and if it is sent to the wrong default gateway for the destination network chosen, then an ICMP (*HOST*) redirect should be issued telling the host which gateway is the correct one to deliver future packets for that network to. Further, once the gateway has the packet, ICMP is out of the picture as all gateways should have up-to-date knowledge as to what the topology currently looks like via a routing protocol such as RIP. There should be absolutely no indecision as to whether it should deliver the packet to G' or G'', etc. and no need for ICMP redirects to be flying around. Also, EGP probably has no bearing at this point as the discussion has been focusing on the problems/advantages of subnets with different size masks, thus the traffic would be internal to the AS and EGP doesn't know about subnets anyway! As a separate discusion, we can talk about the merits of having a different subnet mask on a per interface basis in a gateway as discussed in RFC1009. To my knowledge, no one is implementing this. Does anyone know of any plans? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805140411.AA04259@ucbvax.Berkeley.EDU] <1988051313362500> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: Third TCP-IP Book? Message-ID: <8805140411.AA04259@ucbvax.Berkeley.EDU> Date: 13 May 88 13:36:25 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 IEEE Computer has an ad by Springer-Verlag which beyond listing Davidson's book, also mentions The Complete Guide to TCP/IP Protocol Suite by Don Huntington and George Cohn due out in 1988. I don't know either author and they aren't in the NIC table. Anyone heard anything about this book? Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805140446.AA04773@ucbvax.Berkeley.EDU] <1988051314101600> From: KASTEN@MITVMA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <8805140446.AA04773@ucbvax.Berkeley.EDU> Date: 13 May 88 14:10:16 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 37 > Similarly, I claim that we will need some sort of discovery mechanism >if the list of gateways on a local network is expected to be large and >dynamic. We have such a discovery mechanism in place today; passive >RIP. I'm not recommending that we improve it, or that hosts use it for >anything except finding the first gateway. UNfortunately, not all of the systems that use IP are (easily) capable of running a RIP listener. PC's are the best example - they do not have multitasking, making it difficult to load in a program to listen to the RIP traffic. There are ways of doing it but this is not a forum for discussing PC stuff. >I believe that a gateway can be taught to send out RIP packets saying >"I'm a default router" without sending out any other data. If so, this >would provide my desired discovery mechanism with no changes to a >common flavor of host software (i.e. BSD derivatives). Not all of us are so lucky as to have a BSD system available on which we can build our stuff. I like the idea of the "I am a Router" broadcast's. The problem, again, is that not all hosts may be capable of listening at all times for that broadcast (even a BSD machine could be turned off). Instead, a query and response type of protocol could be used. When a host needs to send something off net and either A) does not have the IP Address of any router (if it had one address, it could send a packet to that router and get the redirect) or B) the host decides that the router it is using is dead (e.g. TCP has retransmitted too often) then the host broadcast a "Who can route to network X?" request and the routers on the local network would respond. This would require changes to both routers and hosts, but I think is the most flexible over the widest range of hosts - from the single "tasked" PC's up to Crays. Of course, you still can listen to RIP (but what if the routers want to use another protocol?) Frank Kastenholz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3046634@um.cc.umich.edu] <1988051314454800> From: Dave_Katz@UM.CC.UMICH.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <3046634@um.cc.umich.edu> Date: 13 May 88 14:45:48 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 27 The OSI approach to this problem is to use the End System-Intermediate System protocol (ISO 9542). In this scheme the ES's (hosts) and IS's (routers) periodically multicast "hello" packets to one another in order to determine reachability. The period used can ultimately be controlled by the IS's. This usually means that address mapping info is already cached so the "hold on a minute while I find out where this packet needs to go" approach that ARP uses is most often not needed. Hosts will discover all routers on the subnet using this mechanism. Redirects are used to teach the hosts which routers to use for particular addresses. The redirects can contain address masks defining equivalence classes of destination addresses to redirect, as well as possibly hinting that the host can algorithmically derive the MAC layer address from the network layer address (OSI NSAP addresses are big enough to embed MAC addresses in them if somebody wants to). This protocol is purposely decoupled from IS-IS routing ("IGP") with the philosophy that hosts should be kept insulated from the details of what happens in the routers, and should be kept simple. Thus the only a priori information needed is the ES's own address. This obviously doesn't help in the TCP/IP world, but it's worth mentioning. --Dave Katz Merit Computer Network/NSFnet Dave_Katz@UM.CC.UMICH.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- [432@anagld.UUCP] <1988051315203000> From: rcsmith@anagld.UUCP (Ray Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: Public domain telnet/ftp Keywords: Me too! Me Too! Message-ID: <432@anagld.UUCP> Date: 13 May 88 15:20:30 GMT References: <1307@ntmtka.UUCP> Reply-To: rcsmith@anagld.UUCP (Ray Smith) Organization: Analytics, Inc., Columbia, MD Lines: 23 In article <1307@ntmtka.UUCP> you write: >I have been asked by an acquaintance from another company (without access to >Usenet) to find out if there are public domain versions of Telnet and FTP >for Unix. ... >Replies can either be posted or emailed directly to me. Thanks. > I am also interested in obtaining public domain Telent/FTP source. Could you please send me a copy of the information you get? Thanks in advance, Ray -- Ray Smith | USnail: Suite 200, 9891 Broken Land Pky, Columbia, MD 21046 Analytics, Inc. | GEnie : rcsmith (301) 381-4300 | CIS : 72000,1111 | Net : ...!uunet!mimsy!aplcen!anagld!rcsmith =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The trouble with doing something right the first time is that nobody appreciates how difficult it was." -Walt West =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22596@bu-cs.BU.EDU] <1988051315545000> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting [struct Enet addr] Summary: Why not have structured Ethernet addressing? Message-ID: <22596@bu-cs.BU.EDU> Date: 13 May 88 15:54:50 GMT References: <8805100150.AA07641@braden.isi.edu> Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.tcp-ip Organization: Boston Univ. Information Tech. Dept. Lines: 30 In article <8805100150.AA07641@braden.isi.edu> braden@VENERA.ISI.EDU writes: >I disagree. The Internet standard approach for a host: pick any >gateway and let it redirect you... is simple and effective. You REALLY >DON'T want hosts to know about routing, even subnet routing!! I agree in principle, but in practice we are talking about hosts on Ethernet LANs with flat address space internetworked on IP wide area networks with hierarchical address space. I don't see any alternative to ARP and gateways. The host has to know when to look directly on the flat address spaced LAN and when to hand off to the gateway for forwarding. This brings me to a question I have been dying to ask for a long time, but just didn't quite know what context to ask it in... It seems so obvious to me that a hierarchically structured address space in Ethernet (read 802.x) 48 bit addresses would be a great improvement over the current kludged 48 bit flat vendor-assigned address space coupled with the 32 bit IP address space that I wonder why the issue never comes up. I know all the obvious problems with structured Ethernet addresses, but everytime I look at the issue it seems to me that structured Ethernet/IP (read 802.x) addresses would be a great improvement over flat address space. I think the 802 spec allows structured addressing, yes? Why is there no hint of movement in this direction? Waiting for ISO? Or have I failed to grasp some essential difficulty with this? Comments, please. Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805140822.AA07844@ucbvax.Berkeley.EDU] <1988051316564800> From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) Newsgroups: comp.protocols.tcp-ip Subject: Re: Doug Comer's TCP/IP book... Message-ID: <8805140822.AA07844@ucbvax.Berkeley.EDU> Date: 13 May 88 16:56:48 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 I read HCCS Vol 3 (By William Stallings - ISBN 0-02-948072-8, MacMillan) and found it to be a good "My First TCP Book" for some technical type of person who is trying to get into the game. It is too much for the non-techie. Haven't read Comer's book yet. Frank Kastenholz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1080@thumper.bellcore.com] <1988051317143700> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: 802 (.2).3 TCP/IP Summary: Ignore 802.2/3 Keywords: interoperability? Message-ID: <1080@thumper.bellcore.com> Date: 13 May 88 17:14:37 GMT References: <1919@ssc-vax.UUCP> Distribution: na Organization: Bell Communications Research, Inc Lines: 25 In my humble opinion, IEEE 802.2/3 is yet another standards committee that the world would have been far better off without. The changes they made to DIX (DEC-Intel-Xerox) Ethernet, already a well-proven de-facto industry standard, were utterly gratuitious. The existing 16-bit type field provided plenty of expansion room to build whatever additional capability they wanted while maintaining compatibility with existing protocol encapsulation formats. The new "length" field not only breaks compatibility, but is useless, redundant information for the protocols that already ran on Ethernet since they have their own type fields. (If a length field was considered necessary for other protocols, it could have been provided AFTER the type field, and only for certain new values in the type field). Because the DIX Ethernet type fields are invalid as 802.3 length values, it is possible to write packet receiver code that will accept, say, IP datagrams in either DIX or 802.3 framing, but real problems come when you need to decide how to SEND packets to another host you haven't spoken to before. I see only one easy answer to the gratuitous compatibility problems imposed by 802.3: IGNORE IT! Also be sure to tell the manufacturers why. Maybe someday the standards-mongers will get the message. (Begin Bernstein music here) Someday, somehow, somewhere... Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805140850.AA08088@ucbvax.Berkeley.EDU] <1988051317190000> From: yurcik@NRL-LCP.ARPA Newsgroups: comp.protocols.tcp-ip Subject: TCP-IP Book of the Month Club Message-ID: <8805140850.AA08088@ucbvax.Berkeley.EDU> Date: 13 May 88 17:19:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The Internet Lines: 18 I also recommend Doug Comer's book. Free enterprise seems to be at its best by giving the network people what they want and creating what I believe will be a major new topic area in the technical book market. I have become aware of another book, "The Complete Guide to TCP/IP" by Don Huntingdon & George Cohn soon to be released by Springer-Verlag, NYC, NY. Can anybody comment on its content? Are the authors out there? Any others thinking about becoming an author? Bill Yurcik "yurcik@nrl-lcp.arpa" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805131727.AA26184@TOTO.MIT.EDU] <1988051317273300> From: mar@ATHENA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: Dumb vs. smart host routing Message-ID: <8805131727.AA26184@TOTO.MIT.EDU> Date: 13 May 88 17:27:33 GMT References: <10285@ulysses.homer.nj.att.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 You are right in that ICMP redirects are only good in indicating the first hop from a host. But that does not make them largely useless, since this is their intended use, and is a valuble part of not requiring hosts to understand complicated routing. This way a host only needs to know about one local gateway *which is currently functioning* and redirects will do the rest. Gateways, on the other hand, must understand routing within their own autonomous system, and to other systems. It is expected that gateways will make use of other protocols for this, not try to use ICMP for something it was not designed for. As in the discussion about how hosts find out about the different first-hop gateways available: the hosts shouldn't listen to RIP, a gateway routing protocol, just as gateways don't for the most part receive ICMP redirects. We will get nothing but trouble if we try to use the same protocols between gateways and for hosts to communicate with gateways. A gateway-to-gateway protocol is necessarily going to be much more complicated than what a host needs, and *will* evolve over time as the internet grows. It should be possible to specify a gateway-to-host protocol in such a way that it is simple and not likely to change so that it will get implemented by all vendors for all operating systems. -Mark Rosenstein ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22607@bu-cs.BU.EDU] <1988051317294700> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Davidson's book vs. Comer's book Summary: We still need another book Message-ID: <22607@bu-cs.BU.EDU> Date: 13 May 88 17:29:47 GMT References: <880512092448.2260d215@Csa4.LBL.Gov> Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.tcp-ip Organization: Boston Univ. Information Tech. Dept. Lines: 11 In article <880512092448.2260d215@Csa4.LBL.Gov> forrest@LBL.GOV writes: >is why I turned to Comer's book. Comer's book is MUCH better although some >of the chapters (specifically those dealing with routing) didn't feel right. >This is probably my fault and I intend to reread the whole book a second time. > No, I felt the same way. The chapter on routing is too brief and left me wanting more. We need still one more book that tackles some of the issues Comer left too briefly treated. Maybe it's too soon. For now, it's back to the RFCs and IDEAs. Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805131920.AA12490@Larry.McRCIM.McGill.EDU] <1988051319203500> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <8805131920.AA12490@Larry.McRCIM.McGill.EDU> Date: 13 May 88 19:20:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 Date: Thu 12 May 88 14:38:09-EDT From: John Romkey Subject: Re: Dumb vs. smart host routing To: jqj@hogg.cc.uoregon.edu Cc: tcp-ip@sri-nic.arpa [ ... ] I envision networks where links to other networks come and go, but not the actual routers themselves. It's a strange idea to me. I don't see any application for it off the top of my head. On our network, which is fairly real-worldish, we have a uVAX-II with very flakey dequna board. It panics several times a day, leaving us with an alternative route but no way to know about it. Your vision could be a little broader, without going over your head. :-) [ ... ] of one default router; I'd like to increase it to an arbitrary list of them which is cycled through for reliability. If you have only one default router Won't this affect your TCP RTT and cause some sort of oscillation (or force you to bind connections to routes)? -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805141153.AA10531@ucbvax.Berkeley.EDU] <1988051319593000> From: MIKEC@csp-a.prime.COM Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8805141153.AA10531@ucbvax.Berkeley.EDU> Date: 13 May 88 19:59:30 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 To: (smb@ulysses.att.com) Cc: (tcp-ip@sri-nic.arpa) From: Michael A. Curtis (mikec@csp-a.prime.com) Date: 13 May 88 3:40 PM Subject: Re: Smart vs. dumb host routing Steve, I think you've missed the whole point of the issue. That is the exact intent of ICMP in this case. Once the host delivers the packet, its job is over and if it is sent to the wrong default gateway for the destination network chosen, then an ICMP (*HOST*) redirect should be issued telling the host which gateway is the correct one to deliver future packets for that network to. Further, once the gateway has the packet, ICMP is out of the picture as all gateways should have up-to-date knowledge as to what the topology currently looks like via a routing protocol such as RIP. There should be absolutely no indecision as to whether it should deliver the packet to G' or G'', etc. and no need for ICMP redirects to be flying around. Also, EGP probably has no bearing at this point as the discussion has been focusing on the problems/advantages of subnets with different size masks, thus the traffic would be internal to the AS and EGP doesn't know about subnets anyway! As a separate discusion, we can talk about the merits of having a different subnet mask on a per interface basis in a gateway as discussed in RFC1009. To my knowledge, no one is implementing this. Does anyone know of any plans? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12398059730.20.BILLW@MATHOM.CISCO.COM] <1988051320160900> From: BILLW@MATHOM.CISCO.COM (William Westfield) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <12398059730.20.BILLW@MATHOM.CISCO.COM> Date: 13 May 88 20:16:09 GMT References: <864@kaos.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 35 Well, I might as well throw some more ideas into the fire. At cisco (where we make routers), we also believe that hosts should know nothing about routing protocols. This becomes much more obvious when your router is running 4 different routing protocols simultaneously, and translating metrics from one to another is both difficult and dangerous. Of course, it ought to be possible to use any of the gateways you've learned about via redirects as new default gateways, but this is probably not easy to add to existing code. However, John Romkey said: If some new protocols were cooked up to allow hosts to query routers for some useful information WITHOUT the hosts understanding how the routers worked, that would be okay as far as I'm concerned. We believe that such a protocol already exists which provides this function, and is implemented by nearly all tcp/ip vendors. It is called ARP. A router can respond to ARP requests that it recognizes as being for hosts not connected to the local cable if it knows a route to that network. This technique is being called "Proxy ARP", and is frequently used to make subnetting transparent to hosts. It works equally well to make any network topology transparent to hosts. Redundancy is handled automatically if you convince TCP and other high level protocols to flush ARP entries when they are about to time out. Of course, this only works with hosts on networks where ARP is used for address resolution (broadcasts are possible). But if a host has only a point-to-point link to the network, it might as well use whatever gateway is at the other end of that link as its default gateway. This leaves only networks like X.25 and the ARPANet (non-broadcast, but not really point-to- point either), and it might not be such a bad idea to have those hosts know about routing, at least to the extent of having multiple default gateways. Bill Westfield cisco Systems. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22611@bu-cs.BU.EDU] <1988051320420600> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Plenum-Rated Ethernet Transceivers Message-ID: <22611@bu-cs.BU.EDU> Date: 13 May 88 20:42:06 GMT References: <859@wright.EDU> <696@applix.UUCP> Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.tcp-ip Organization: Boston Univ. Information Tech. Dept. Lines: 26 In article <696@applix.UUCP> mark@applix.UUCP (Mark Fox) writes: >we were assured (not sure by whom -- it was 4+ years ago) that it was >ok from a legal standpoint to install normal yellow PVC cable in plenums >as long as smoke detectors were also present (in the plenums). It certainly >is cheaper than installing Teflon cable or using metal conduit (at least >in the absence of fire!) > >Anybody know if this is true today? Any specific building/fire code references >available? Thanks. We went through all this, too, and in Boston there are code provisions for allowing PVC [non rated] cable in return air plenums when there are smoke detectors tied into the air handling system that shut down the air circulation in the event of fire. Unfortunately, there is no relation between Boston codes and state of Mass codes and national codes, since it is possible for the state and city to override and change any provision of the national codes. You MUST verify compliance to code for each and every building project with the inspectors, they have the last word. When talking to your architects and general contractors, ask for an air handling system that does not require fire rated cable. Leave it to them to figure out how to do it. Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [360@halley.UUCP] <1988051320491300> From: bc@halley.UUCP (Bill Crews) Newsgroups: comp.protocols.tcp-ip Subject: Re: another TCP/IP book Message-ID: <360@halley.UUCP> Date: 13 May 88 20:49:13 GMT References: <8805112228.AA28127@hogg.cc.uoregon.edu> Reply-To: bc@halley.UUCP (Bill Crews) Organization: Tandem Computers, Austin, TX Lines: 16 John Davidson's book, An Introduction to TCP/IP is exactly that, an introduction. As such, it is likely to be less involving and intimidating than Doug's book for someone who would rather read a quarter inch of paper and know something than to read an inch of stuff. It's likely that most netters have a sufficient interest in TCP/IP to warrant choosing Doug's book, which looks excellent, though I haven't read it yet. But many netters, and perhaps the majority of TCP/IP users in general, might be better served by a shorter overview of TCP/IP, such as John's book. The bad news is that they apparently cost about the same, even though John's book is a quarter inch softback. Oh, well... -bc -- Bill Crews Tandem Computers bc@halley.UUCP Austin, Texas ..!rutgers!im4u!halley!bc (512) 244-8350 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12398124710.18.ROMKEY@XX.LCS.MIT.EDU] <1988051402130600> From: ROMKEY@XX.LCS.MIT.EDU (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <12398124710.18.ROMKEY@XX.LCS.MIT.EDU> Date: 14 May 88 02:13:06 GMT References: <8805131920.AA12490@Larry.McRCIM.McGill.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 > On our network, which is fairly real-worldish, we have a uVAX-II with > very flakey dequna board. It panics several times a day, leaving us with > an alternative route but no way to know about it. Your vision could be > a little broader, without going over your head. :-) Originally we were discussing 'extremely dynamic' router changes. A crash every few hours doesn't cut it with me for 'extremely dynamic'. There are two things that should be done here. First, the microvax should be fixed. Second, the software should have the list of default gateways that I keep bringing up rather than just one. > Won't this affect your TCP RTT and cause some sort of oscillation (or force > you to bind connections to routes)? Not a problem at all. You cache a route for each connection; if the connection starts having problems or an appropriate redirect is received, you recompute the route. It's very simple and quite efficient if implemented correctly. - john ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805140345.AA03402@ETN-WLV.EATON.COM] <1988051403454400> From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) Newsgroups: comp.protocols.tcp-ip Subject: Re: controlling IP "type of service" Message-ID: <8805140345.AA03402@ETN-WLV.EATON.COM> Date: 14 May 88 03:45:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Mike, Its been a while since I've read the RFP. Is Dave trying to say that a CRITIC is less important than a Flash or Flash Override? Merton ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051404350000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sat, 14 May 88 05:36:22 PDT Date: 14 May 1988 08:35-EDT Sender: CERF@A.ISI.EDU Subject: Re: controlling IP "type of service" From: CERF@A.ISI.EDU To: Mills@LOUIE.UDEL.EDU Cc: stjohns@BEAST.DDN.MIL, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]14-May-88 08:35:09.CERF> In-Reply-To: <8805122131.aa12584@Huey.UDEL.EDU> Dave, does the precedence queueing inyour Fuzzballs account for some of the very long-delayed packets showing up in the Internet from time to time? Under heavy load, unless you have a time-dependent priority system, some packets may stay in queue quite a while as higher precedence traffic goes by. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5388@umn-cs.cs.umn.edu] <1988051406195600> From: haque@dg.cs.umn.edu (Samudra E. Haque) Newsgroups: comp.protocols.tcp-ip,comp.misc Subject: TCP/IP implementations for DG/UX on MV series Hardware (was Honeywell and DG) Keywords: LONG Message-ID: <5388@umn-cs.cs.umn.edu> Date: 14 May 88 06:19:56 GMT References: ACC-SB-U.8805091745.AA24461 Sender: news@umn-cs.cs.umn.edu Reply-To: haque@dg.cs.umn.edu (Samudra E. Haque) Organization: University of Minnesota, Minneapolis. Lines: 127 Posted: Sat May 14 01:19:56 1988 >From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) >Date: 9 May 88 17:45:19 GMT >> I am going to be running Honeywell and Data General systems on a >>LAN soon and have been told by a customer that they have TCP/IP implement- >>ations running on them. Does anyone have any comments, suggestions, war >>stories or anything else that relates to these implementations? I have never I run a MV10000 machine with Data General native unix here at the Computer Science Laboratories, current revision of the OS is 3.11 and revision of the TCP/IP portion is 2.1 I believe. Summary of TCP/IP on DG machines: not bad, but could be better. You might want to be aware of a couple of things "peculiar" or "unique" to Data General Unix software: Disclaimer: Your mileage may vary in proportion to the relation you have with the company and its sales offices. a) There ARE people directly connected with Data General on the net and who have access to this and other newsgroups. Maybe they'd like to publicise their own product some day? [Dg-Rtp people:With the recent Unix announcement by De Castro, don't you think your management would love a few extra customers? :-) ] b) Currently DG has several TCP/IP packages with different O/S's: AOS/VS with MV/UX (Unix) as a sub-process. DG/UX native Unix (SVID compatible System V/BSD 4.2) We used to have AOS/VS at our site but about 9 months ago switched over to DG/UX. While the cutover itself was painless, and while DG/UX makes our machine a far better and useful CPU on the whole, lack of good networking utilities hampered us a bit. Also something that really hurt us was the "inability" for DG/UX to communicate with certain vendor machines including other MV series machines themselves. Some of these problems are currently under going investigation (Data General has a very good customer support service at least), but here are a few details: 1) Most of the code for the TCP/IP version 2.1 coupled with DG/UX 3.11 were written in 1985 or 1986. code currently is predominantly based on 4.2 code with *ALL* of the bugs still present. 2) No nameserver support. 3) Occasionally some of our SUN-2's and SUN-3's will not be able to communicate with the MV and vice-versa. 4) I find it impossible to work from an MV10000 <->MV20000 over the arpanet using DG/UX 3.11 and TCP/IP. Connections will inevitably hang or refuse to start at all. 5) In one nasty case, we found that they had ('as a result of a design decision in previous revisions ') written parts of the O/S code that relied on a particular level of revisions of the boards inside the CPU including the ILC (intelligent lan controller). What would happen if you weren't running that particular level was that occasionally (read: randomly) there was the possibility of a board being *IGNORED* by the CPU. Only a hardware reset would bring that board back up! There was no fix except to *up* the hardware, and if it happens again I'm tearing somebody's desk in half. b) Things ARE going to change: (All for the better I hope) 1) revision numbers are going to be standardised. Thus DG/UX revision 4, due out mid summer is going to have TCP/IP rev 4. 2) nameserver support will be provided. 3) new code fixing trailing headers and other problems The reason for this change in progress is the advent of DG/UX revision 4: (100% system V and 80-90% BSD, according to sales reps). Data General wants to get into the Unix market with a stronger line of products and hence it has just recently increased support of DG/UX internally. Overall I have heard DG/UX revision 4 to be a worthwile operating system. c) Currently DG/UX has neat stuff like NFS/YP (we use NFS, but not YP) pretty good implementations, except for lacking in symbolic links (fixed in rev 4 of course). It has also the standard BSD 'R' functions : rsh/rlogin etc. etc. Programming with TCP/IP isn't that bad from my limited experience with it, ( I ported RRN at least) like any other piece of software that is to exist in a hybrid environment the following apply: 1) If you use system independent packages (i.e. curses and not terminfo) software will tend to port easier. 2) If you really really REALLY want to break a piece of software - you will be able to. 3) Rtfm,rtfm, RTFM! d) Corporate Software support is good now from the customer support center in Atlanta, GA - but it could be a lot better. It used to be until a few weeks ago that the first level reps would not know the remotest Unix type questions even if you told them the page number of the manual to look at. Again, with the turn towards unix, more and more staff are taking Unix classes. (I can just see it now: "you mean if I do a 'ls' it will print out the same information as the DIR command in AOS/VS? ":-) If they (DGC software problem management dept), happen to fix a bug, then often times they will give you binaries of all the programs ($22,000 for source code if you are inclined to buy it) and they won't even provide the *.o modules for convinience. That means of course you *have* to be upto date with the software revisions. Other than that - I don't have much to say. (i've already said enough don't you think?). Again, it's raining now but the outlook for the future is clear and getting warmer. Oh, I think 75 F, and 35% humidity please.. Cheers! Samudra E. Haque Computer Science Laboratories, Computer Science Department University of Minnesota, Minneapolis, MN 55455 (1)-(612)-625-0876 || haque@dg.cs.umn.edu || umn-cs!haque%dg.cs.umn.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]14-May-88.08:35:09.CERF] <1988051412350000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: controlling IP "type of service" Message-ID: <[A.ISI.EDU]14-May-88.08:35:09.CERF> Date: 14 May 88 12:35:00 GMT References: <8805122131.aa12584@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Dave, does the precedence queueing inyour Fuzzballs account for some of the very long-delayed packets showing up in the Internet from time to time? Under heavy load, unless you have a time-dependent priority system, some packets may stay in queue quite a while as higher precedence traffic goes by. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805141610.AA04585@ETN-WLV.EATON.COM] <1988051416103600> From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <8805141610.AA04585@ETN-WLV.EATON.COM> Date: 14 May 88 16:10:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Binding connections to routes is not necessarily bad. Binding connections to routes will probably be a necessity if, and when, multi-level security is implemented. Not all gateways, hosts, etc. may be accredited to service a transmission at a given security level. Which we lead to some requirement for a node to be able to request of each node in a path "can you provide me this class (type) of service at this security level?" Merton ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12398287383.24.LYNCH@A.ISI.EDU] <1988051417064100> From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Third TCP-IP Book? Message-ID: <12398287383.24.LYNCH@A.ISI.EDU> Date: 14 May 88 17:06:41 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 The supposed "Complete Guide to TCP/IP ..." will not be out this spring. I talked to one of the purported authors about it this week and he said that he had to back out of th eproject because of overload, but that the project was still being pursued. I did'nt get a date, but my reading is summer/fall. All these books on TCP/IP are wonderful. Finally we have something(s) to give to people that expalins what we have been doing for the past decade. I have reviewed all three extant books and each has it merits and faults. I may as well go on record, so to speak, about my views on them to help others decide which to get for which purpose. These views are my own (who else???). Comer's book is extremely thorough on the lower layers (up through TCP). It gives an outstanding exposition of th eneed for internetting and addresses the common and ugly cases in a clear style. An excellent book for the technically inclined. This book is weak on the application protocols.It explains them, but does not delve very deeply into them. Stalling's book is very thorough on the application layer protocols and not very strong on the lower layers. I think of it as trying to explain Ip and TCP from an ISO viewpoint. While technically clean, it lacks motivation. Davidson's book is good material to give to a marketing person. It explains al the terms, much of the history, and does not dig too deeply. It is a short book (around 100 pages) and is essentially an annotated glossary. So, all three books have their place. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805141910.AA16517@apptek6] <1988051419105600> From: len@spam.istc.sri.COM (Len Schlegel) Newsgroups: comp.protocols.tcp-ip Subject: Synchronous input performance question Message-ID: <8805141910.AA16517@apptek6> Date: 14 May 88 19:10:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Forgive me if this question is inappropriate for this group. In unix systems it seems that you can block awaiting input on some socket in two ways. Either you use a blocking socket and then read (or block at a select call) and continue when input arrives, or have your socket set so that a SIGIO is generated when input arrives, at which point you do your read (or select) in your signal handler. The blocking can be achieved by using the sigpause call. In the later case, the socket can be non-blocking. The question is are there performance implications in using one approach over the other. Thanks, Len Schlegel len@spam.istc.sri.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805141604.aa02984@Huey.UDEL.EDU] <1988051420041600> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: controlling IP "type of service" Message-ID: <8805141604.aa02984@Huey.UDEL.EDU> Date: 14 May 88 20:04:16 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Merton, I takes the bits as they come. All ones is the greatest and all zeros the least most mortals could aspire. I plead resistant to any semantic exercise that attempts to match Internet reality with Precedence mappings. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805142022.AA25315@beno.CSS.GOV] <1988051420220300> From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: Public domain telnet/ftp Message-ID: <8805142022.AA25315@beno.CSS.GOV> Date: 14 May 88 20:22:03 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 Are there vendors that provide TCP/IP without FTP/TELNET? If so, you need a hell of a lot more than just FTP to do anything. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805141634.aa03069@Huey.UDEL.EDU] <1988051420340100> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: controlling IP "type of service" Message-ID: <8805141634.aa03069@Huey.UDEL.EDU> Date: 14 May 88 20:34:01 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 Vint, Verily in an FB(n) system dudes at higher priority levels can freeze out dudes at lower priority levels if the volume of traffic at the higher levels is sufficiently intense. There is now doubt that this occasionally occurs when the NSFNET Backbone is sore abused by certain 4.2bsd systems that have not upgraded to 4.3bsd with the Jacobson/Karels pollution controls (point made - I have not yet found a way to reliably identify 4.2bsd abusers and stamp their passports with priority zilch). While the freezees can shiver in the queues as the hotrods whiz by, they can't freeze for longer than their TTL, for most systems not over thirty seconds and for no systems longer than about four minutes. What usually happens is that, a packet below the eutectic can't live more than a few seconds before being preempted anyway. Such is live in the present 56-kbps world. Fancier schemes can readily be proposed to improve fairness with FB(n) systems, many of which were first proposed in the CTSS days when timesharing was losing its hyphenation. In context of six weeks the existing 56-kbps backbone is to live before being retired hy the new 1.5-Mbps backbone, there is small chance that these schemes will be implemented. There may be at least a month before the new backbone will have to face the same problems. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3303@saturn.ucsc.edu] <1988051420394200> From: eshop@saturn.ucsc.edu (Jim Warner) Newsgroups: comp.protocols.tcp-ip Subject: Excelan and subnets Keywords: Excelan RFC950 Message-ID: <3303@saturn.ucsc.edu> Date: 14 May 88 20:39:42 GMT Organization: U.C. Santa Cruz, CIS/CE. Lines: 9 Does Excelan's TCP/IP for MS-DOS support subnets yet? The version I have (EXOS 8051-02 Ver 3.2.5 Rev B) does not. My sales critter isn't sure what RFC950 subnetting is and I don't think I'm going to get an answer from him. Are there any other good reasons to upgrade? Jim Warner ** 408-429-2606 University of Ca Santa Cruz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805142225.AA28581@sccgate.scc.com] <1988051422254700> From: oconnor@sccgate.scc.COM (Michael J. O'Connor) Newsgroups: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted Message-ID: <8805142225.AA28581@sccgate.scc.com> Date: 14 May 88 22:25:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 2 Any points for noting the mistake on page 40? Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805150047.AA04159@BITSY.MIT.EDU] <1988051500471400> From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <8805150047.AA04159@BITSY.MIT.EDU> Date: 15 May 88 00:47:14 GMT References: <8805140444.AA13986@ATHENA.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 > ...When a host needs to send >something off net and either A) does not have the IP Address of any >router (if it had one address, it could send a packet to that router >and get the redirect) or B) the host decides that the router it is >using is dead (e.g. TCP has retransmitted too often) then the host >broadcast a "Who can route to network X?" request and the routers on >the local network would respond. Now be VERY careful with protocols that broadcast questions that may get simultaneously answered by a large number of machines. In a network with only one or two routers what you suggest would work fine. However when you have about 20 routers on an Ethernet you are likely to get a monster Ethernet collision when they all go to respond to the broadcast. There have been several horror stories posted to this mailing list of "monster collision" problems (I know, I was one of the senders!). ARP works using broadcast questions, but in a properly functioning network exactly one machine should respond, so no collision. However you do bring up a problem with single threaded machines. What if we modify your scheme so that all routers on a network speak some (as yet undefined) protocol to elect one of them the "advertised default router" and only this router would respond to the "Who can route" message. If this router went down the other routers would know and elect a new default router. [Note I have simplified the question from "Who can route to network X?" to just a simple request for a default router. That router can then send redirects later when packets arrive.] -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805141700.0.UUL1.3#948@fernwood.mpk.ca.us] <1988051501001100> From: geoff@fernwood.mpk.ca.us (Geoff Goodfellow) Newsgroups: comp.protocols.tcp-ip Subject: Mail Order TCP-IP. Message-ID: <8805141700.0.UUL1.3#948@fernwood.mpk.ca.us> Date: 15 May 88 01:00:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: fernwood!Geoff@Sun.COM Organization: The Internet Lines: 6 What with three books available or soon to be on TCP-IP, take note in the latest Black Box Catalog... TCP-IP is now available via mail order. Diners Club International, Carte Blance, Master Charge, American Express and Visa accepted! From a PDP-11/20 via a Very Distant Host connection to SRI from Vint Cerf's Lab at Stanford to a mail order house & just about every plastic charge plate. TCP-IP has (almost?) become a consumer item. Next stop.... Radio Shack? Geoff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805150343.AA07983@bu-cs.bu.edu] <1988051503431200> From: bzs@bu-cs.bu.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Synchronous input performance question Message-ID: <8805150343.AA07983@bu-cs.bu.edu> Date: 15 May 88 03:43:12 GMT References: <8805141910.AA16517@apptek6> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 >In unix systems it seems that you can block awaiting input on some socket in >two ways. Either you use a blocking socket and then read (or block at >a select call) and continue when input arrives, or have your >socket set so that a SIGIO is generated when input arrives, at which >point you do your read (or select) in your signal handler. The blocking >can be achieved by using the sigpause call. In the later case, the socket >can be non-blocking. > The question is are there performance implications in using >one approach over the other. You'd probably do well directing questions like this to unix-wizards@sem.brl.mil (I think that's the appropriate host name.) Doing the read alone is clearly lower overhead as the signal mechanism requires several things to happen as well as the ultimate read, you pay what you get for. Whether it's "high" or "unacceptable" overhead is an entirely differnet question and depends on the motivation which brought the question up. If you were doing nothing but looping in data I can't see any reason to incur the signal overhead. If you sometimes needed the non-blocking behavior than you have a reason to do that, etc etc. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [881@kaos.UUCP] <1988051506291400> From: romkey@kaos.UUCP (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting [struct Enet addr] Message-ID: <881@kaos.UUCP> Date: 15 May 88 06:29:14 GMT References: <8805100150.AA07641@braden.isi.edu> <22596@bu-cs.BU.EDU> Reply-To: romkey@kaos.UUCP (John Romkey) Organization: Chaos; Somerville, MA Lines: 50 In article <22596@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: > I agree in principle, but in practice we are talking about >hosts on Ethernet LANs with flat address space internetworked on IP >wide area networks with hierarchical address space. I don't see any >alternative to ARP and gateways. The host has to know when to look >directly on the flat address spaced LAN and when to hand off to the >gateway for forwarding. Easy. If your host has only one network interface, then just do this: if((my_ip_address & my_subnet_mask) == (dest_ip_address & my_subnet_mask)) first_hop = dest_ip_address; else { first_hop = default_routers[next_default_router++]; next_default_router %= number_of_default_routers; } Then send the packet to the IP address on your physical network given by 'first_hop'. > It seems so obvious to me that a hierarchically structured >address space in Ethernet (read 802.x) 48 bit addresses would be a >great improvement over the current kludged 48 bit flat vendor-assigned >address space coupled with the 32 bit IP address space that I wonder >why the issue never comes up. I know all the obvious problems with >structured Ethernet addresses, but everytime I look at the issue it >seems to me that structured Ethernet/IP (read 802.x) addresses would >be a great improvement over flat address space. I think it would be a bad idea to give up the 48 bits of addressing. 48 bits is more than we'll ever need, right? Fine, then let's keep it that big. *Maybe* we'll really never need it bigger (yes, I can't remember if 2^48 is greater than the estimated number of particles in the Universe...if it is, that's even better). So let's not take any of the current 48 bits to form the hierarchical address. The only reason that I think you'd really want to have hierarchical ethernet addresses is if you want to use them as your IP level 'logical' addresses, but if you do that then you open up lots of problems: the addresses must be variable length if you want to support more media than just those that use ethernet-style addresses, which is really nasty from an implementation point of view (like ISO, which in general is really nasty from an implementation point of view); and you end up with volatile addresses wired into IP-level addresses which have a (presumably) long lifetime - when your ethernet interface goes to bit heaven, you don't want your computer's IP address to change. -- - john romkey UUCP: romkey@kaos.uucp ARPA: romkey@xx.lcs.mit.edu ...harvard!spdcc!kaos!romkey Telephone: (617) 776-3121 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [882@kaos.UUCP] <1988051506442200> From: romkey@kaos.UUCP (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: Proxy ARP (was Re: Dumb vs. smart host routing) Message-ID: <882@kaos.UUCP> Date: 15 May 88 06:44:22 GMT References: <864@kaos.UUCP> <12398059730.20.BILLW@MATHOM.CISCO.COM> Reply-To: romkey@kaos.UUCP (John Romkey) Organization: Chaos; Somerville, MA Lines: 36 Bill, I hate to do this, but I don't like proxy ARP at all. There are two reasons for why: First, there are too many network media that don't use ARP for my taste. ARPANET, X.25, ProNET-10. Maybe FDDI won't? I look at what you said about these media this way: you're going to have to support default gateways on them. You want the vendor to support it. The vendor's IP layer should probably be pretty media-independent, so if you've got default routers working in the software when you hook up a system to the ARPANET, you've basically got what you need for ethernet too. So it's not really an extra work to support it for networks other than the non-ARP media. Second, I had a really bad experience with an ethernet at MIT that had a proxy ARP router on it a few years ago. Dave Bridgham was setting up a second IP subnet on an ethernet at LCS. But a strange thing was happening - his packets were disappearing. The proxy ARP router was sending out ARP replies few milliseconds after the host Dave was trying to talk to and it ended up gobbling up all the packets. It took us a long time to track down the problem. I think there are situations where you might want to set up a second, test IP subnet or network on an network cable which already has a different IP subnet or network on it, and that proxy ARP routers which might believe they're doing exactly the right thing would make it impossible to do this. So proxy ARP is unacceptable to me. -- - john romkey UUCP: romkey@kaos.uucp ARPA: romkey@xx.lcs.mit.edu ...harvard!spdcc!kaos!romkey Telephone: (617) 776-3121 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051510544400> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Sun, 15 May 88 14:39:16 PDT To: geoff@fernwood.mpk.ca.us cc: tcp-ip@sri-nic.ARPA Subject: re: Mail Order TCP-IP. Date: Sun, 15 May 88 17:34:44 -0400 From: Craig Partridge > What with three books available or soon to be on TCP-IP, take note in the latest > Black Box Catalog... Geoff, Does the catalog offer Vint Cerf decoder rings? I've been searching for one for some time now.... :-) Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051511523200> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Mon, 16 May 88 20:44:28 PDT Received: from UKACRL.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 8592; Mon, 16 May 88 15:57:28 EDT Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 0182; Mon, 16 May 88 19:31:48 BST Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 0179; Mon, 16 May 88 19:31:48 BS Via: UK.AC.STRATH.VAXD; 16 MAY 88 19:31:43 BST Date: 16-MAY-1988 19:32:32 GMT From: CDBP01%VAXD.STRATHCLYDE.AC.UK@CUNYVM.CUNY.EDU To: TCP-IP@SRI-NIC.ARPA Subject: Toothpaste, but also *disinfectant*! TCP in Britain is actually the name for a brand of disinfectant! (Tri-Chloro Phenol is reputedly the company's excuse for using these initials) Competition time: how many uses for liquid TCP could be found for Real TCP? Answers on a line to: Alan Fleming Strathclyde University Glasgow, Scotland. CDBP01%VAXD.STRATHCLYDE.AC.UK@CUNYVM.CUNY.EDU (I Think!) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051513490000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Sun, 15 May 88 15:54:44 PDT Date: 15 May 88 18:49:00 EST From: Subject: Decoder Rings To: "craig" cc: Craig: What the community really needs is a good Mills decoder ring! Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051518002800> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Sun, 15 May 88 19:15:20 PDT Received: from NIHCU.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 6082; Sun, 15 May 88 22:02:49 EDT To: TCP-IP@SRI-NIC.ARPA, "Campus-Size LAN Discussion Group" From: "Roger Fajman" Date: Sun, 15 May 88 22:00:28 EDT Subject: Packet size distribution Does anyone have any data on the distribution of packet sizes on an Ethernet? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805151450.aa09254@Huey.UDEL.EDU] <1988051518500400> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Timewarp alert Message-ID: <8805151450.aa09254@Huey.UDEL.EDU> Date: 15 May 88 18:50:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 Folks, At about 2000 UT Saturday the NCAR primary NTP time server took a hit, with result that until about 1800 UT Sunday the year read 99, not 88. At about 0100 UT Saturday the UDel primary NTP time server also took a hit and chimed similar nonsense until fixed about an hour later. In all the NTP primary servers the year is determined (from a file) at boot time and can be changed subsequently only by an operator command. The year information is not part of the timecodes broadcast by NBS. In fact, I can find no evidence of TCP login near the time of warp in either case and have no reason to suspect operations staff at either location of any mischief. I therefore tentatively have classified the warps as zoo events and have alerted the hacker trackers. Those brave enough to be chiming NTP with one or more of the five NTP primary time servers should read Appendix D of the document found in the ~ftp/pub/ntp.doc file in the anonymous login at louie.udel.edu. This appendix suggests that secondary NTP time servers should peer with two of the five primary servers along with another secondary server known to peer with two different primary servers. The voting algorithm used by the Fuzzball and Unix daemons is designed to cast out falsetickers most effectively in such configurations. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805152250.AA04470@ucbvax.Berkeley.EDU] <1988051521344400> From: craig@SH.CS.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: Mail Order TCP-IP. Message-ID: <8805152250.AA04470@ucbvax.Berkeley.EDU> Date: 15 May 88 21:34:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 > What with three books available or soon to be on TCP-IP, take note in the latest > Black Box Catalog... Geoff, Does the catalog offer Vint Cerf decoder rings? I've been searching for one for some time now.... :-) Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805152224.AA27935@orc.olivetti.com] <1988051522241800> From: roode@orc.olivetti.COM (David Roode) Newsgroups: comp.protocols.tcp-ip Subject: network cost recovery Message-ID: <8805152224.AA27935@orc.olivetti.com> Date: 15 May 88 22:24:18 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 114 There are benefits of usage insensitive cost recovery as applied to networking, through the need for universal connectivity and the common immeasurable benefit derived therefrom. This is much as it has traditionally been recognized in not basing service fees on incremental cost to provide service for such applications as mailing a letter or installing a new telephone line (for a rural location vs. a metrapolitan area). The recent analogy of garbage dumpster capacity being used as a gauge for waste removal charges was interesting. So was the observation that sewage charging is often based on another available metric--fresh water consumption. In these cases society has a vested interest in making the billing not directly usage sensitive. Who would want his neighbors piling up sewage or garbage rather than disposing of it? In the case of garbage removal, it is probably more common for there to be a fixed fee per household rather than to let the act of renting a dumpster invoke a higher fee for the removal. This makes the charge less usage-based still. Nonetheless, all costs are recovered. I don't like the loading of network service fees on top of actual costs of a leased line to effect the feeder connection. It treats as negligible cases of particular 9600 baud circuits passing more data than some 56Kb circuits. Why deny light-usage sites rapid throughput for that usage? Aside from very crude load leveling, it seems needless. I submit that innovative funding sources could remove the argument that fully usage sensitive charging is needed at any level. At the same time, the main difficulty I see in usage sensitive charging is an extremely painful transition, for all the reasons that have been cited. We could get there, but the casualties and setbacks along the way would be inevitable. Certain non-usage based charging would evolve anyway, so why not consider an alternative? My claim is that there is a way to scale the charging schemes of the past to match the popularity of networks of the present. Such a step is much less drastic and offers advantages as well as a smoother transition. I agree with Craig Partridge's idea of charging only at the feeder connection and not worrying about exactly what passes through that connection and where it is going. The cost of doing detailed accounting is considerable, so if we avoid this we have just obtained one subsidy to network usage. On the other hand, accounting only on raw usage of a site's feeder connection need not be onerous and offers benefits over charging based solely on the existence of the feeder connection. I feel that network charging should not be based only on feeder circuit size (and maybe not that at all, beyond passing on the raw costs of providing the feeder circuit itself). Instead consider the community to be served by that circuit, including its size and its nature, and the general level of usage of the circuit. This could be quite managable, and I will propose some necessary elements of a workable realization of this alternative to all-out bean counting: (1) Educational and non-profit sites should get discounts, government should pay a little more, and others (e.g. commercial) should pay the most of all for a given service. (2) Smaller communities (all kinds) should get discounts to encourage their participation. (3) Increasing the participation by commercial research organizations which pay their own freight and then some will significantly add to the subsidy of research networking infrastructure currently paid only by the government. This subsidy is not workable if attempted on a usage-sensitive basis, i.e. the subsidy has to be a flat one. (4) Within a category, a year's fees should be set in advance based on the previous year's usage. This provides administrative convenience for all concerned. (5) Organizations which offer identifiable service to the community at large should be assessed based on an appropriately discounted usage level. (6) An estimate would be used for the first year of an organization's connection. (7) No bill backs would be used for deviations over the period of the fee year. This sort of volume pricing has ample precedent in volume purchase agreements commonly in use. (8) Organizations which can not afford the new year's rates should be given the ability to invoke a throttle, by downgrading link size or limiting throughput. The limits should be settable across a smooth set of incremental values. (9) In general, organizations will be encouraged to find a means to distribute costs, especially since these will approximate benefit to the organization in that they are based loosely on volume. Furthermore, they will be proportional to the organization's ability to pay. They will be designed so as to encourage payment out of research overhead, which fully usage-sensitive charges are not, and the cost will be known in advance and will be controllable. This scheme can be used by any network that chooses to adopt it. Interconnections between networks, except in special cases like the NSFNET backbone, provide mutual benefit to both networks, and no charges need be levied. Each network pays part of the costs. A fellow in Australia mentioned increased equity if usage-sensitive charges were employed in the U.S. since it already is in the case of the Australia-UUNET link. It's important to note that UUNET is merely an interface service to the vast UUCP network, which itself has no central services or central charging scheme of any sort, usage sensitive or not. It's this which causes the inequity where Australia pays all the costs of the UUNET link. UUNET has no way to assess charges on all the USENET users who use the link, and aside from direct UUNET participants also has no way to recover network overhead costs. UUCP is a different sort of network backbone than the type of which we speak in the TCP-IP discussion. Furthermore the Australia and other international UUCP network connections are special cases insofar as even UUCP is concerned. I could envision support for that link from the network administrations of the many U.S. networks other than the UUCP network, all of which are TCP-IP based except for BITNET. I am sure all value mail connectivity with Australia and other nations. There is a Federation of these networks which would be the right place to bring up the issue. However, only the costs of the international X.25 connection and not the cost of that part which occurs within a nation should be borne mutually. The part of the path within a given nation is reciprocated by that part within the destination nation. I.e., when Australia exchanges mail with the U.S. it is currently not billed for use of a significant distribution network. The U.S. distribution net is used for all messages between the two countries, originating in either. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805160035.AA06066@ucbvax.Berkeley.EDU] <1988051523490000> From: enger@bluto.scc.COM Newsgroups: comp.protocols.tcp-ip Subject: Decoder Rings Message-ID: <8805160035.AA06066@ucbvax.Berkeley.EDU> Date: 15 May 88 23:49:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Craig: What the community really needs is a good Mills decoder ring! Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051601130000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon, 16 May 88 02:14:58 PDT Date: 16 May 1988 05:13-EDT Sender: CERF@A.ISI.EDU Subject: Re: controlling IP "type of service" From: CERF@A.ISI.EDU To: Mills@LOUIE.UDEL.EDU Cc: stjohns@BEAST.DDN.MIL, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]16-May-88 05:13:47.CERF> In-Reply-To: <8805141634.aa03069@Huey.UDEL.EDU> Dave, I forgot about TTL - in that case, how do you explain such long-delayed packets that arrive well in excess of TTL? Did they take paths that didn't examine TTL (e.g. hosts offering unauthorized gateway services?). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805160352.AA08554@ucbvax.Berkeley.EDU] <1988051602002800> From: RAF@NIHCU.BITNET ("Roger Fajman") Newsgroups: comp.protocols.tcp-ip Subject: Packet size distribution Message-ID: <8805160352.AA08554@ucbvax.Berkeley.EDU> Date: 16 May 88 02:00:28 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 2 Does anyone have any data on the distribution of packet sizes on an Ethernet? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805152226.aa12175@Huey.UDEL.EDU] <1988051602262400> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Mail Order TCP-IP. Message-ID: <8805152226.aa12175@Huey.UDEL.EDU> Date: 16 May 88 02:26:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Craig, I think you mean Cerfboards, not decoder rings. These can be used to escape alligators in the swamps, entangle sausage nets and even fry fuzzballs. Vint can tell you TCP is a mouthwash sold in Britain and what cooks in a bakeoff. Nevertheless, I don't think any of the older buzzards in the Internet coop ever thought you could buy TCP-IP with a credit card, much less a Cerfboard. Lest we forget Premier Buzzard Bob Kahn, you should know there is a pawnshop in Wellington, New Zealand called the Kahn Store, where you just might find a better bargain. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805152243.aa12339@Huey.UDEL.EDU] <1988051602430400> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Decoder Rings Message-ID: <8805152243.aa12339@Huey.UDEL.EDU> Date: 16 May 88 02:43:04 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Bob, The decoder ring is next to the Rosetta Stone, which is on your left as you enter the British Museum. It resembles a Moebius strip with Linear-B on one side and ALGOL-68 on the other. Allegedly, it was found in an ancient burial mound near Ur along with pieces of Cerfboard and embedded in Millstone. You have to talk like this if you want to become an Internet Buzzard. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [410190444@nwnexus.WA.COM] <1988051605032600> From: edm@nwnexus.WA.COM (Ed Morin) Newsgroups: comp.protocols.tcp-ip,comp.sys.dec Subject: Re: Plenum-Rated Ethernet Transceivers Keywords: plenum transceiver ethernet Message-ID: <410190444@nwnexus.WA.COM> Date: 16 May 88 05:03:26 GMT References: <859@wright.EDU> Reply-To: edm@nwnexus.WA.COM (Ed Morin) Organization: Northwest Nexus Inc., Seattle, WA Lines: 20 I was recently faced with the same problem while installing a network in a building that uses the air space above the ceiling for the cold air return of the air-conditioning system. Since we were ordering Cabletron transceivers, I knew that everything would be ok. However, once we re- ceived the transceivers they had little stickers on them saying (I don't have one with me at the moment) that they could *not* be used in "pleums"! So, I contacted Cabletron. Normally I get terrific service and attention from them, but this fiasco went on for *weeks* trying to reconcile this apparent inconsistency. Nobody seemed to know anything about the meaning of their NEC 725 (?) specification vs. this crazy sticker with an apparent misspelling. It turns out that the transceivers can be put into "air handling *spaces*" (like ceilings), but *not* in actual ducting (i.e. main air supplies, etc.). I guess Cabletron is drawing a distinction between an "air handling" spaces and "plenums"... Ed Morin Northwest Nexus Inc. edm@wa.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051605372400> Received: from MITVMA.MIT.EDU by SRI-NIC.ARPA with TCP; Mon, 16 May 88 06:47:37 PDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 2495; Mon, 16 May 88 09:45:20 EDT Received: by MITVMA (Mailer X1.25) id 2494; Mon, 16 May 88 09:45:19 EDT Date: Mon, 16 May 88 09:37:24 EDT From: Frank Kastenholz Subject: Re: Dumb vs. smart host routing To: "Jeffrey I. Schiller" In-Reply-To: Your message of Sat, 14 May 88 20:47:14 EDT Cc: jqj@HOGG.CC.UOREGON.EDU, tcp-ip@SRI-NIC.ARPA > However you do bring up a problem with single threaded >machines. What if we modify your scheme so that all routers on a >network speak some (as yet undefined) protocol to elect one of them >the "advertised default router" and only this router would respond to >the "Who can route" message. If this router went down the other >routers would know and elect a new default router. "Note I have >simplified the question from "Who can route to network X?" to just a >simple request for a default router. That router can then send >redirects later when packets arrive." The basic idea is good, unfortunately, I need to deal in the real world (SHUDDER) where a certain well known computer company has made a network package for PC's and PS/2's that does not understand ICMP redirect. In fact, the only ICMP that this package supports is Address Mask Query. Cheers Frank Kastenholz ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051606320000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Mon, 16 May 88 20:44:03 PDT Received: from VCUVAX.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4171; Mon, 16 May 88 11:36:58 EDT Date: Mon, 16 May 88 11:32 EST From: (Bob Langford) Subject: How many levels should a domain-style name have? To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, LANGFORD Hi, I've got a question about domain naming schemes. We're hooking up a university-wide network using IP/TCP, which will soon be connected to SURAnet/NSFnet. Naturally, we want to set up some domain-style names for our systems, but we're having some disagreements about how many levels the names should have, i.e., RUBY.VCU.EDU vs RUBY.MCV.VCU.EDU (no one thinks we need 5 levels!) We will have about 10 "large" hosts (>10 users), about 5-10 small hosts (1-2 user Suns) and dozens of Macintoshes or PCs connected on subnets. Many people here want 3 level names for ease of remembering, others want 4 level names for distributed naming (node addresses will be assigned by distributed means, not a central authority). Some months ago, someone suggested assigning nodes 4 level names, but also providing a 3 level "alias" for the most popular systems. Is this wise and/or feasible? What do most places do? (Extra info: most of our computers are Pyramids using UNIX, with a few Sun 3/xxx systems, and a VAX/VMS system running Wollongong software.) Bob Langford MCV Academic Computing Virginia Commonwealth University (804) 786-9843 Bitnet: LANGFORD @ VCUVAX ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]16-May-88.05:13:47.CERF] <1988051609130000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: controlling IP "type of service" Message-ID: <[A.ISI.EDU]16-May-88.05:13:47.CERF> Date: 16 May 88 09:13:00 GMT References: <8805141634.aa03069@Huey.UDEL.EDU> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Dave, I forgot about TTL - in that case, how do you explain such long-delayed packets that arrive well in excess of TTL? Did they take paths that didn't examine TTL (e.g. hosts offering unauthorized gateway services?). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805161108.AA09443@uunet.UU.NET] <1988051610484700> From: mo@maximo.UUCP (Mike O'Dell) Newsgroups: comp.protocols.tcp-ip Subject: toothpaste Message-ID: <8805161108.AA09443@uunet.UU.NET> Date: 16 May 88 10:48:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 It was somewhere in Europe, Copenhagen, I think, that I saw a tube of something named "TCP" in a shop window. It turned out to be toothpaste. I regret not having bought some. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805161554.AA17695@ucbvax.Berkeley.EDU] <1988051613372400> From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <8805161554.AA17695@ucbvax.Berkeley.EDU> Date: 16 May 88 13:37:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 > However you do bring up a problem with single threaded >machines. What if we modify your scheme so that all routers on a >network speak some (as yet undefined) protocol to elect one of them >the "advertised default router" and only this router would respond to >the "Who can route" message. If this router went down the other >routers would know and elect a new default router. "Note I have >simplified the question from "Who can route to network X?" to just a >simple request for a default router. That router can then send >redirects later when packets arrive." The basic idea is good, unfortunately, I need to deal in the real world (SHUDDER) where a certain well known computer company has made a network package for PC's and PS/2's that does not understand ICMP redirect. In fact, the only ICMP that this package supports is Address Mask Query. Cheers Frank Kastenholz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3152@cheviot.newcastle.ac.uk] <1988051614230300> From: nmsg@newcastle.ac.uk (Newcastle Micro Support Group) Newsgroups: comp.protocols.tcp-ip Subject: Request for Tektronix 4014 TELNET (Repost) Keywords: Telnet Tektronix_4014 SSMP Programming Message-ID: <3152@cheviot.newcastle.ac.uk> Date: 16 May 88 14:23:03 GMT Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE17RU Lines: 12 Does anyone have knowledge of a Tektronix 4014 version of TELNET ? I have a PC with a 3com card in it and a version of KA9Q, which gives me tty access to various hosts. I would like to use some graphics. Any thoughts... Additionally I would like to be able to call out and use SSMP (Simple Screen Management Protocol) programs on the remote hosts, and this involves an SSMP version of TELNET. I think I'll probably have to do some programming. Can anyone point me in the direction of some really straightforward programming interfaces into TCP/IP code? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3604@psuvax1.psu.edu] <1988051614295000> From: ehrlich@blitz (Dan Ehrlich) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Competition for Bridge Keywords: TCP-IP. Bridge. Message-ID: <3604@psuvax1.psu.edu> Date: 16 May 88 14:29:50 GMT References: <599@riddle.UUCP> Sender: netnews@psuvax1.psu.edu Reply-To: ehrlich@blitz (Dan Ehrlich) Organization: Department of Computer Science, Penn State University Lines: 21 In article <599@riddle.UUCP> andrew@riddle.UUCP (Andrew Beattie) writes: >Does anyone other than Bridge make Ethernet TCP/IP Terminal servers? > Let's see now: 1) Encore Computer - Annex Terminal Server 2) CISCO We have all three, Bridge, Encore, CISCO, here at Penn State. I have had experience only with Bridge and Encore. Of the two I would recommend the Encore over the Bridge any day. Dan Ehrlich The Pennsylvania State University, Department of Computer Science 333 Whitmore Laboratory, University Park, PA 16802 +1 814 863 1142 or +1 814 865 9723 Dan Ehrlich The Pennsylvania State University, Department of Computer Science 333 Whitmore Laboratory, University Park, PA 16802 +1 814 863 1142 or +1 814 865 9723 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805161044.aa18465@Huey.UDEL.EDU] <1988051614443800> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: controlling IP "type of service" Message-ID: <8805161044.aa18465@Huey.UDEL.EDU> Date: 16 May 88 14:44:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Vint, So far as I know, no gateways except fuzzballs take care to calculate the actual time in queue when decrementing TTL. I of course would invite corrections to that presumption. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805161055.aa18694@Huey.UDEL.EDU] <1988051614551200> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: toothpaste Message-ID: <8805161055.aa18694@Huey.UDEL.EDU> Date: 16 May 88 14:55:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Mike, Thanks for the info. The British TCP claim comes from Jack Haverty at BBN, Internet Engineer-Buzzard emeritus. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805161514.AA02390@lear.ultra.com] <1988051615142900> From: wayne@ultra.UUCP (Wayne Hathaway) Newsgroups: comp.protocols.tcp-ip Subject: Re: toothpaste and other TCPs Message-ID: <8805161514.AA02390@lear.ultra.com> Date: 16 May 88 15:14:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 It wasn't that long ago that some major US oil company was screaming the wonders of adding TCP to its gasoline (was that what gave Shell gas its extra mileage?), although this particular TCP has been a well-known gasoline additive for years (spelled phonetically as something like "tri-creasel-phosphate"). Wonder what it would do for the mileage of a motor-driven Cerfboard? Wayne Hathaway ultra!wayne@Ames.ARPA Ultra Network Technologies 2140 Bering drive with a domain server: San Jose, CA 95131 wayne@Ultra.COM 408-922-0100 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805161548.AA15786@oliver.cray.com] <1988051615482900> From: dab@oliver.CRAY.COM (Dave Borman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <8805161548.AA15786@oliver.cray.com> Date: 16 May 88 15:48:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 Bill Westfield of cisco Systems while talking about "Proxy ARP" writes: > Of course, this only works with hosts on networks where ARP is used for > address resolution (broadcasts are possible). But if a host has only a > point-to-point link to the network, it might as well use whatever gateway > is at the other end of that link as its default gateway. This leaves only > networks like X.25 and the ARPANet (non-broadcast, but not really point-to- > point either), and it might not be such a bad idea to have those hosts know > about routing, at least to the extent of having multiple default gateways. There's more. For instance, the A series of HYPERchannel adaptors does not support broadcast, and is not point-to-point. As far as I know, "Proxy ARP" only works with subnets, for nodes that don't know about subnets. In order to send out the ARP request, the host has to already belive that he can get to the remote host in one hop. If my machine is on net 128.62, and I want to get to a machine on net 128.63, I don't send out an ARP request for the machine on net 128.63. I have to have a route to 128.63 which points to a machine on net 128.62, and then I'll be ARPing for the machine on 128.62 which is the next hop to 128.63. "Proxy ARP" is a wonderful fix in the real world to keep your subnetted network running when you have hosts that don't know about subnets. I don't think that it should be used for anything else, or promoted as a standard. -Dave Borman CRAY Research, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805180042.AA07446@ucbvax.Berkeley.EDU] <1988051616320000> From: LANGFORD@VCUVAX.BITNET (Bob Langford) Newsgroups: comp.protocols.tcp-ip Subject: How many levels should a domain-style name have? Message-ID: <8805180042.AA07446@ucbvax.Berkeley.EDU> Date: 16 May 88 16:32:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 Hi, I've got a question about domain naming schemes. We're hooking up a university-wide network using IP/TCP, which will soon be connected to SURAnet/NSFnet. Naturally, we want to set up some domain-style names for our systems, but we're having some disagreements about how many levels the names should have, i.e., RUBY.VCU.EDU vs RUBY.MCV.VCU.EDU (no one thinks we need 5 levels!) We will have about 10 "large" hosts (>10 users), about 5-10 small hosts (1-2 user Suns) and dozens of Macintoshes or PCs connected on subnets. Many people here want 3 level names for ease of remembering, others want 4 level names for distributed naming (node addresses will be assigned by distributed means, not a central authority). Some months ago, someone suggested assigning nodes 4 level names, but also providing a 3 level "alias" for the most popular systems. Is this wise and/or feasible? What do most places do? (Extra info: most of our computers are Pyramids using UNIX, with a few Sun 3/xxx systems, and a VAX/VMS system running Wollongong software.) Bob Langford MCV Academic Computing Virginia Commonwealth University (804) 786-9843 Bitnet: LANGFORD @ VCUVAX ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805161802.AA15658@mtxinu.UUCP] <1988051617555700> From: minshall@kinetics.UUCP (Greg Minshall) Newsgroups: comp.protocols.tcp-ip Subject: hosts and gateways and protocols Message-ID: <8805161802.AA15658@mtxinu.UUCP> Date: 16 May 88 17:55:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 44 This is a very nice and timely discussion for me, given where I am in some product development cycle. What my tendancy has been is to allow for the specification of a default router (yes, just one). If the router isn't specified, then we listen for RIP broadcasts. Now, I never know what is INSIDE a RIP packet. However, I choose a default router based on the largest RIP packet seen, and I stay with that router for five minutes or so. So, if I continue getting RIP packets, then I keep following routers. Whenever I receive a host or network ICMP redirect, I update my *HOST* route (based on the destination IP address which comes along with the ICMP packet). This host route lives for five minutes or so (maybe 20 minutes). It then times out, and we use the current default router to send to (the router may then send back a redirect, which we will believe). I am very sympathetic to almost all sides of this debate. I strongly believe that hosts should stay out of the routing game. I strongly *wish* all hosts had only one interface, but that isn't always desireable. I also feel for those souls whose routers occasionally crash, and who would like routes to switch automatically. I don't believe that just because you need this capability once per day that should exclude it from being automated. Right now, listening for RIP packets is, in many environments, the best way to locate potential gateways. There is no reason this needs to have a separate process listening - consider these packets to be like ICMP packets. As a design issue, I think that the ISO scheme seems very well thought out. I want to be able to hear "I'm a router and I'm alive" packets at a fairly high rate (at least once per minute). I tend to lean towards unsolicited broadcasts (multicasts, whatever) from the routers rather than a "query-response" scheme ("any routers out there?" "here I am") for a few reasons. First off, there are many more hosts than gateways, so the unsolicited broadcasts should generate less (broadcast or multicast) traffic. Second, I'd rather not have to worry about how a uni-directional UDP stream is supposed to decide that its packets aren't making it to the other end of the wire. Third, I'm not sure that every time TCP retransmits a packet I want to have to revalidate the route. Greg Minshall Kinetics, Inc. 415-947-0998 ucbvax!mtxinu!kinetics!minshall ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1988.05.16.13.40.02.retrac.16163@titan.rice.edu] <1988051618400100> From: retrac@RICE.EDU (John Carter) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet size distribution Message-ID: <1988.05.16.13.40.02.retrac.16163@titan.rice.edu> Date: 16 May 88 18:40:01 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Roger, When I ran a series of traces of our ethernet (which my or may not be particularly representative), I found that most packets were either very small (e.g. ARP, RIP, telnet packets) or very large (e.g. FTP). Small packets were the most common. Large packets tended to come in bursts (such as when a user loads a file in to a workstation). Medium sized packets were fairly uncommon. There is a paper entitled "Network Measurement of the VMTP Request-Response Protocol in the V Distributed System" by Cheriton and Williamson in 1987 ACM Sigmetrics Conference on Measurement and Modeling of Computer Systems. They found that there was a similar distribution for VMTP packets. John Carter Rice University retrac@rice.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [14933@sgi.SGI.COM] <1988051619032400> From: vjs@rhyolite.SGI.COM (Vernon Schryver) Newsgroups: comp.protocols.tcp-ip Subject: Re: 802 (.2).3 TCP/IP Summary: yes, but how to make it work anyway? Keywords: interoperability? Message-ID: <14933@sgi.SGI.COM> Date: 16 May 88 19:03:24 GMT References: <1919@ssc-vax.UUCP> <1080@thumper.bellcore.com> Sender: daemon@sgi.SGI.COM Distribution: na Organization: Silicon Graphics Inc, Mountain View, CA Lines: 31 In article <1080@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes: > I see only one easy answer to the gratuitous compatibility problems > imposed by 802.3: IGNORE IT! ... Yes, but...some vendors are already supporting it. I'm told by some of our customers that Gould/SEL machines can do either 'Ethernet 1 or 802.3' (meaning either lengths or types), depending on boot-time configuration, and cannot send even raw ethernet packets of one kind when configured for the other. I've heard more distressing claims about WIN/TCP for HP-3000's. This may not be true about either (it's only our customers beating up on us, demanding interoperability), but it will no doubt eventually be true of some machines. It's likely we, at SGI, can figure out how to make our drivers hear either the old form or RFC-1042. What should we do for output? -Add an option to ifconfig which tells the driver to speak RFC-1042? -A per-driver, system configuration option? -Some kind of hack for ARP like that for trailers? Send both kinds of ARP request and guess out what each destination wants by what you get back? But that makes the MTU for the link kind of variable. It might be confusing when two such machines talk to each other--depending on timing, they might get different conclusions about each other. What about proxy-ARP? It might be nice if the 4.3bsd compatible vendors could be consistent. If the problem has been solved, please forgive me, and tell me the solution. Vernon Schryver Silicon Graphics vjs@sgi.com or {pyramid,decwrl,research,allegra,adobe,sun}!sgi!vjs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805180210.AA08976@ucbvax.Berkeley.EDU] <1988051619323200> From: CDBP01@VAXD.STRATHCLYDE.AC.UK Newsgroups: comp.protocols.tcp-ip Subject: Toothpaste, but also *disinfectant*! Message-ID: <8805180210.AA08976@ucbvax.Berkeley.EDU> Date: 16 May 88 19:32:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 TCP in Britain is actually the name for a brand of disinfectant! (Tri-Chloro Phenol is reputedly the company's excuse for using these initials) Competition time: how many uses for liquid TCP could be found for Real TCP? Answers on a line to: Alan Fleming Strathclyde University Glasgow, Scotland. CDBP01%VAXD.STRATHCLYDE.AC.UK@CUNYVM.CUNY.EDU (I Think!) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3680@hqda-ai.ARPA] <1988051619511600> From: merlin@hqda-ai.ARPA (David S. Hayes) Newsgroups: comp.protocols.tcp-ip Subject: What is Batch FTP? Message-ID: <3680@hqda-ai.ARPA> Date: 16 May 88 19:51:16 GMT Reply-To: merlin@hqda-ai.ARPA (David S. Hayes) Organization: Army AI Center, Pentagon Lines: 10 I recently saw an article in "comp.sources.wanted" that made passing reference to a Batch FTP program. I have never heard of Batch FTP. Can anyone enlighten me? Thanks, -- David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900 UUCP: *!uunet!cos!hqda-ai!merlin ARPA: merlin@hqda-ai.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880516153824.20600B3D081@nssdca.GSFC.NASA.GOV] <1988051620382400> From: PETERS@nssdca.GSFC.NASA.GOV (Dave.Peters@SRI-NIC.ARPA, NASA/GSFC/NSSDC) Newsgroups: comp.protocols.tcp-ip Subject: TCP in the UK Message-ID: <880516153824.20600B3D081@nssdca.GSFC.NASA.GOV> Date: 16 May 88 20:38:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 I recently returned from a year in the United Kingdom where quite often I would notice large signs saying "TCP AOK". Rather than attempting to sell new implementations of TCP/IP for your favourite BBC micro, the adverts were for a topological disinfectant of some sort. I wonder if the active ingredient was that same TCP petrol additive... Dave Peters ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1084@thumper.bellcore.com] <1988051623202600> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: toothpaste Summary: Another TCP product? Message-ID: <1084@thumper.bellcore.com> Date: 16 May 88 23:20:26 GMT References: <8805161108.AA09443@uunet.UU.NET> Organization: Bell Communications Research, Inc Lines: 13 The stuff I have a sample of is a topical anesthetic, for burns, cuts, etc. I'm not sure I'd want to brush my teeth with it -- the label says it contains phenol and iodine. What I *really* like is the picture I have of a British advertising poster for it. It says, in large, friendly letters, No Need for XYZ, Just TCP! Take THAT, CCITT!! :-) Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [684@tetra.NOSC.MIL] <1988051623471500> From: budden@tetra.NOSC.MIL (Rex A. Buddenberg) Newsgroups: comp.protocols.tcp-ip Subject: Re: Decoder Rings Message-ID: <684@tetra.NOSC.MIL> Date: 16 May 88 23:47:15 GMT References: <8805160035.AA06066@ucbvax.Berkeley.EDU> Reply-To: budden@tetra.nosc.mil.UUCP (Rex A. Buddenberg) Organization: Naval Ocean Systems Center, San Diego Lines: 3 Not quite -- in Dave's case, a ring will only do if it tells time. How 'bout a decoder watch? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13614@comp.vuw.ac.nz] <1988051701414800> From: mark@comp.vuw.ac.nz (Mark Davies) Newsgroups: comp.protocols.tcp-ip Subject: Re: Mail Order TCP-IP. Message-ID: <13614@comp.vuw.ac.nz> Date: 17 May 88 01:41:48 GMT References: <8805152226.aa12175@Huey.UDEL.EDU> Reply-To: mark@comp.vuw.ac.nz (Mark Davies) Organization: Comp Sci, Victoria Univ, Wellington, New Zealand Lines: 15 In article <8805152226.aa12175@Huey.UDEL.EDU> Mills@UDEL.EDU writes: >Lest we forget Premier Buzzard Bob Kahn, you should know there is a pawnshop >in Wellington, New Zealand called the Kahn Store, where you just might find >a better bargain. I've lived in Wellington for the last 20 years and hadn't heard of this store. Just checked the phone book and discovered that it did exist, but Kahns the pawnshop (actually a TV repairman) has closed down (It is now an Antique shop). You will have to try somewhere else. Of course they may always have an NCP implementation---but you know how expensive Antique shops are! ;-) mark -- Domainised: mark@comp.vuw.ac.nz Bang form: ...!uunet!vuwcomp!mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051702334900> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Tue, 17 May 88 06:23:52 PDT To: Frank Kastenholz cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Dumb vs. smart host routing In-reply-to: Your message of Mon, 16 May 88 09:37:24 -0400. Date: Tue, 17 May 88 09:13:49 -0400 From: Mike Brescia a certain well known computer company has made a network package for PC's and PS/2's that does not understand ICMP redirect. This is an interesting turn. What if they try to send to a gateway that does not forward packets which needed redirect. a. host sends to gw A b. gw A redirects host to gw B c. gw A now has no more buffers, drops pkt d. host ignores redirect e. go to a The IP spec does imply some effort be made to forward a redirected packet, but I interpret the priority to be higher to get the redirect to the host, and only secondary that the packet be forwarded. Mike Brescia, BBNCC gateway group ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805170308.AA12239@vax.ftp.com] <1988051703080400> From: jbvb@VAX.FTP.COM (James Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: "topological disinfectant" Message-ID: <8805170308.AA12239@vax.ftp.com> Date: 17 May 88 03:08:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 ... is clearly something that maintainers of routing protocols need to have handy at all times... jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805170444.AA20271@Larry.McRCIM.McGill.EDU] <1988051704444300> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) Newsgroups: comp.protocols.tcp-ip Subject: Re: Proxy ARP (was Re: Dumb vs. smart host routing) Message-ID: <8805170444.AA20271@Larry.McRCIM.McGill.EDU> Date: 17 May 88 04:44:43 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 I think there are situations where you might want to set up a second, test IP subnet or network on an network cable which already has a different IP subnet or network on it, and that proxy ARP routers which might believe they're doing exactly the right thing would make it impossible to do this. So proxy ARP is unacceptable to me. But you should be able to configure a router to not know about a network, and therefore not answer requests about it (to `unknow' the network, as it were). If you can't do this, it reflects a flaw in the implementation, not the protocol. -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805170455.AA20399@Larry.McRCIM.McGill.EDU] <1988051704550500> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) Newsgroups: comp.protocols.tcp-ip Subject: Re: Davidson's book vs. Comer's book Message-ID: <8805170455.AA20399@Larry.McRCIM.McGill.EDU> Date: 17 May 88 04:55:05 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 >>is why I turned to Comer's book. Comer's book is MUCH better although some >>of the chapters (specifically those dealing with routing) didn't feel right. >>This is probably my fault and I intend to reread the whole book a second time. >No, I felt the same way. The chapter on routing is too brief and left >me wanting more. We need still one more book that tackles some of the >issues Comer left too briefly treated. Maybe it's too soon. For now, >it's back to the RFCs and IDEAs. I enjoyed Doug's book also, and thought the "Hints to Implementors" was a great idea (there should be a 10 Most Deadly Sins RFC [like don't forward MAC broadcast packets, for instance]). The routing was a little thin, however. A novice might not really see the significance of the extra-hop problem, and the EGP description was too short. And even though EGP-3 is still a moving target, a separate chapter about that (maybe talking about LANDMARK and Dissimilar Gateway Protocol) would be good. To be sure, though, it was an very good book. -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051704554500> Received: from IBM.COM by SRI-NIC.ARPA with TCP; Tue, 17 May 88 06:16:04 PDT Date: 17 May 88 08:55:45 EDT From: Nicholas Simicich To: mcc@etn-wlv.eaton.com, tcp-ip@sri-nic.arpa Message-Id: <051788.085546.njs@ibm.com> Subject: Re: Dumb vs. smart host routing > From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) > > Binding connections to routes is not necessarily bad. Binding connections > to routes will probably be a necessity if, and when, multi-level security > is implemented. Not all gateways, hosts, etc. may be accredited to service > a transmission at a given security level. Which we lead to some requirement > for a node to be able to request of each node in a path "can you provide me > this class (type) of service at this security level?" > > Merton Sure, I'll handle your secure traffic. Sure, I'll encrypt it for you. I think that the originator has to get this information from internal tables, or a trusted server on a trusted path, at the least. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051705393900> Received: from MITVMA.MIT.EDU by SRI-NIC.ARPA with TCP; Tue, 17 May 88 06:49:48 PDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 1318; Tue, 17 May 88 09:48:08 EDT Received: by MITVMA (Mailer X1.25) id 1317; Tue, 17 May 88 09:48:06 EDT Date: Tue, 17 May 88 09:39:39 EDT From: Frank Kastenholz Subject: Re: Dumb vs. smart host routing To: Mike Brescia In-Reply-To: Your message of Tue, 17 May 88 09:13:49 -0400 cc: tcp-ip@SRI-NIC.ARPA >From: Mike Brescia > > > a certain well known computer company has made a network package for PC's > and PS/2's that does not understand ICMP redirect. > >This is an interesting turn. What if they try to send to a gateway that does >not forward packets which needed redirect. > a. host sends to gw A > b. gw A redirects host to gw B > c. gw A now has no more buffers, drops pkt > d. host ignores redirect > e. go to a >The IP spec does imply some effort be made to forward a redirected packet, but >I interpret the priority to be higher to get the redirect to the host, and >only secondary that the packet be forwarded. If this occurs then I imagine that the host will remain mute for all eternity. I was not able to try anything like this though - we are just going to tell our customers that "Here is a failure mode that we (ATEX) can not fix - so if it occurs, ......." We have aother PC based (using the P.D. MIT PC/IP code) product that will have "multiple default" gateways, as was discussed on the list earlier. The transport/application layer will ask IP to try another route in the event of excessive transmission errors (i.e. no receipt of an ACK) Cheers Frank Kastenholz Atex/EPPS - a Kodak Company All opinions are mine and in no way belong to Atex/EPPS/Kodak (in fact they don't even know that I am saying this) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805170601.AA21125@Larry.McRCIM.McGill.EDU] <1988051706013800> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) Newsgroups: comp.protocols.tcp-ip Subject: Re: Third TCP-IP Book? Message-ID: <8805170601.AA21125@Larry.McRCIM.McGill.EDU> Date: 17 May 88 06:01:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Quick thought (often the deadliest): why not divide Doug's book into two volumes (chapters 1-16, and 17-$)? Then he would not be constrained by length or cost (more pages == higher cost). It seems likely that some people would probably only need one of the two, anyway. -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051706025700> Received: from clash.cisco.com by SRI-NIC.ARPA with TCP; Tue, 17 May 88 13:33:04 PDT Received: from clash.cisco.com by clash.cisco.com with TCP; Tue, 17 May 88 13:02:59 PDT To: "Jeffrey I. Schiller" Cc: KASTEN@mitvma.mit.edu, jqj@hogg.cc.uoregon.edu, tcp-ip@sri-nic.arpa, cire@clash.cisco.com Subject: Re: Dumb vs. smart host routing In-Reply-To: Your message of Sat, 14 May 88 20:47:14 -0400. <8805150047.AA04159@BITSY.MIT.EDU> Date: Tue, 17 May 88 13:02:57 PDT From: cire@clash.cisco.com >> Date: Sat, 14 May 88 20:47:14 EDT >> From: Jeffrey I. Schiller >> To: KASTEN@MITVMA.MIT.EDU >> Cc: jqj@HOGG.CC.UOREGON.EDU, tcp-ip@SRI-NIC.ARPA >> Subject: Re: Dumb vs. smart host routing >> >> ... >> >> simplified the question from "Who can route to network X?" to just a >> simple request for a default router. That router can then send >> redirects later when packets arrive.] >> >> -Jeff A reasonable idea. It still requires the hosts involved to implement some kind of redundancy mechanism if the default router goes down. But it would not have to know about routing just that it needs to find a new default. -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805170607.AA21182@Larry.McRCIM.McGill.EDU] <1988051706070700> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) Newsgroups: comp.protocols.tcp-ip Subject: Re: Mail Order TCP-IP. Message-ID: <8805170607.AA21182@Larry.McRCIM.McGill.EDU> Date: 17 May 88 06:07:07 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 > I think you mean Cerfboards, not decoder rings. These can be used to escape > alligators in the swamps, entangle sausage nets and even fry fuzzballs. Vint > can tell you TCP is a mouthwash sold in Britain and what cooks in a bakeoff. I thought the mouthwash was called "VAX69"? -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051709351700> Received: from EDN-UNIX.ARPA by SRI-NIC.ARPA with TCP; Tue, 17 May 88 10:50:20 PDT Date: 17 May 1988 13:35:17 EDT From: Edward A. Cain Subject: Re: toothpaste In-Reply-to: Your message of Mon, 16 May 88 06:48:47 EDT To: maximo!mo@uunet.UU.NET (Mike O'Dell) Cc: tcp-ip@sri-nic.arpa, Mike, Please check carefully before using TCP in a tube. The British product is an ointment for piles, not toothpaste. If it's good for both, it's truly an end-to-end product. (heh) The two other TCP products I have, both from England, are the liquid anti-septic and the throat pastilles (lozenges). "For sore throats suck TCP ..." Ed Cain ----MESSAGE-END---- ----MESSAGE-BEGIN---- [501@sering.cwi.nl] <1988051711383700> From: piet@cwi.nl (Piet Beertema) Newsgroups: comp.protocols.tcp-ip Subject: Re: toothpaste Message-ID: <501@sering.cwi.nl> Date: 17 May 88 11:38:37 GMT References: <8805161108.AA09443@uunet.UU.NET> Organization: CWI, Amsterdam Lines: 9 ...that I saw a tube of something named "TCP" in a shop window. It turned out to be toothpaste. TCP sounds like a natural abbreviation for Tooth Cleaning Paste. -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10294@ulysses.homer.nj.att.com] <1988051712071500> From: smb@ulysses.homer.nj.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Decoder Rings Message-ID: <10294@ulysses.homer.nj.att.com> Date: 17 May 88 12:07:15 GMT References: <8805160035.AA06066@ucbvax.Berkeley.EDU> <684@tetra.NOSC.MIL> Organization: AT&T Bell Laboratories, Murray Hill Lines: 1 A decoder ring network, perhaps? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051712120000> Received: from nrl-lcp.arpa by SRI-NIC.ARPA with TCP; Tue, 17 May 88 13:28:01 PDT Date: 17 May 88 16:12:00 EDT From: Subject: Washington DC Area ACM-SIGCOMM Meeting 6/17 To: "tcp-ip" cc: yurcik Reply-To: As a result of the responses from Redskins Fans from all over... ******************************************************************************* WASHINGTON DC SIGCOMM Association for Computing Machinery Washington, D.C. Chapter Special Interest Group on Data Communications NETWORK ROUNDTABLE #2 Topic : "NETWORK MANAGEMENT" ============================== DATE: Friday, June 17, 1988 TIME: 1:00 p.m. to 5:00 p.m. PLACE: Naval Research Laboratory Building 222 Auditorium Washington D.C. 20375-5000 RESERVATIONS: RSVP *ONLY* with Ms. Kelly Short 8:00AM-3:30PM, (202) 767-3887 If Ms. Short is unavailable please call back since she is the only maintainer of the list. All attendees must RSVP by June 10th because names must be left at the guard posts for entry onto the base. For security reasons, non-U.S. citizens and foreign nationals might not be able to attend if special arrangements are not made in advance. For additional information, contact Bill Yurcik, "yurcik@nrl-lcp.arpa" or (202) 767-3903. DIRECTIONS: Carpooling advised due to parking limitations. Located just off Interstate 295 near the Capitol Beltway (I-95) and the Wilson Bridge on the Maryland Shoreline of the Potomac River. Signs off I-295 clearly mark the Laboratory exits from the north and south. Following is directions to the North Gate of NRL which is the closest gate to Building 222. FROM THE SOUTH: Take the Capitol Beltway to Maryland exit 2 (I-295 North) on the Maryland side of the Wilson Bridge. From I-295 take exit 1 (NRL), turn right at the first light onto Overlook Avenue and then make a left at the next light onto Chesapeake Street. Proceed slowly with a 15 mph monitored speed limit. Stop at the outer guard house and identify yourself as attending a meeting at NRL. Continue past 2 more stop signs, stop at the NRL guard post and identify yourself by your RSVP name and ask directions if needed. Bldg. 222 is directly on your left past the gate but parking may be best available by bearing right and parking along the river. FROM THE NORTH: Take the Capitol Beltway to Maryland exit 22B, (BW Parkway/I-295 South) and follow I-295 past New York Avenue and Bolling Air Force Base. Take exit 1 (NRL), proceeeding straight past one light, and turn right at the 2nd light onto Chesapeake Street. Note that Chesapeake Street has a 15 mph monitored speed limit. Stop at the outer guard house and identify yourself as attending a meeting at NRL. Continue past 2 more stop signs, stop at the NRL guard post to identify yourself by your RSVP name and ask directions if needed. Bldg. 222 is directly on your left past the gate but parking may be best available by bearing right and parking along the river. DRAFT AGENDA PROGRAM: 1:00-1:10 Greeting/Introduction B. Yurcik/ACM member E. Gardner/SIGCOMM,Chair GUEST SPEAKER: 1:10-2:00 Keynote Address V. Cerf/Corporation for VINT CERF "Network Management" National Research Initiative/ National Chair ACM SIGCOMM 2:00-2:20 Break ROUNDTABLES: Area facility network architects, managers, and implementors will have an opportunity to share experiences and discuss technology issues in response to prepared questions and open questions from the audience. 2:20-3:15 Roundtable - "Network Management and the Internet" (Moderated by Vint Cerf) Corporation for Open Systems - Howard Berkowitz NSF - unnamed Proteon - unnamed SURANET - Jack Hahn Vitalink Corp. - Tim Lee-Thorpe University of Maryland - Mike Petry 3:20-5:00 Roundtable - "Network Management and the Campus LAN" (Moderated by Walt Roehr, Executive Telecommunication Networks) Cisco Corp. - unnamed DEC - unnamed IBM - unnamed NASA Goddard - J. Pat Gary National Bureau of Standards - Craig Hunt Naval Research Laboratory - Mac Mcculloch/Bill Fink ******************************************************************************** ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805171238.AA25118@terra.mitre.org] <1988051712383800> From: mcleod@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: End-User Performance Measurements Message-ID: <8805171238.AA25118@terra.mitre.org> Date: 17 May 88 12:38:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 This year at MITRE, we have a task for the DDN PMO to look at network performance as seen by an end-user. I an interpreting 'end-user' to be an application protocol, such as TELNET or FTP, to discount the variability in application protocol implementations. This task includes finding metrics (such as response time and throughput) that define end-user performance (we are starting with ANSI X3.102), building a prototype system to measure those metrics on top of TCP, and actually doing some measurements and writing about the experience (what numbers did we get, what lessons about measuring the network did we learn). In order to also learn from the community (I don't believe we are the first to attempt end-user performance measurements) I am interested in collecting information about other end-use performance measurement tools and experiences. In particular, I would like to know 1)what metrics were used, 2)how they were measured, 3)what type of tool is used - a separate application or measurements within an application layer protocol (like FTP), and 4)any problems or lessons learned about using the tool, doing end-user measurements, doing the data analysis, etc. Please respond to me directly -- mcleod@gateway.mitre.org -- I will summarize to the list, if people are interested. Thank you. Sue McLeod The MITRE Corporation, McLean, Virginia ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805171310.AA03117@tut.cis.ohio-state.edu] <1988051713104300> From: tom@TUT.CIS.OHIO-STATE.EDU (Tom Easterday) Newsgroups: comp.protocols.tcp-ip Subject: Re: Competition for Bridge Message-ID: <8805171310.AA03117@tut.cis.ohio-state.edu> Date: 17 May 88 13:10:43 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Dan, Could you give me a name and number for someone at Encore and CISCO to talk to about their terminal servers. Here at The Ohio State Univ. we currently have Bridge equipment (and have been relatively pleased with it) but I would like to cover all the bases. Thanks for your time. Tom Easterday Instruction and Research Computer Center The Ohio State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805172214.AA04977@ucbvax.Berkeley.EDU] <1988051713134900> From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <8805172214.AA04977@ucbvax.Berkeley.EDU> Date: 17 May 88 13:13:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 a certain well known computer company has made a network package for PC's and PS/2's that does not understand ICMP redirect. This is an interesting turn. What if they try to send to a gateway that does not forward packets which needed redirect. a. host sends to gw A b. gw A redirects host to gw B c. gw A now has no more buffers, drops pkt d. host ignores redirect e. go to a The IP spec does imply some effort be made to forward a redirected packet, but I interpret the priority to be higher to get the redirect to the host, and only secondary that the packet be forwarded. Mike Brescia, BBNCC gateway group ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805192145.AA23123@ucbvax.Berkeley.EDU] <1988051713393900> From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <8805192145.AA23123@ucbvax.Berkeley.EDU> Date: 17 May 88 13:39:39 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 >From: Mike Brescia > > > a certain well known computer company has made a network package for PC's > and PS/2's that does not understand ICMP redirect. > >This is an interesting turn. What if they try to send to a gateway that does >not forward packets which needed redirect. > a. host sends to gw A > b. gw A redirects host to gw B > c. gw A now has no more buffers, drops pkt > d. host ignores redirect > e. go to a >The IP spec does imply some effort be made to forward a redirected packet, but >I interpret the priority to be higher to get the redirect to the host, and >only secondary that the packet be forwarded. If this occurs then I imagine that the host will remain mute for all eternity. I was not able to try anything like this though - we are just going to tell our customers that "Here is a failure mode that we (ATEX) can not fix - so if it occurs, ......." We have aother PC based (using the P.D. MIT PC/IP code) product that will have "multiple default" gateways, as was discussed on the list earlier. The transport/application layer will ask IP to try another route in the event of excessive transmission errors (i.e. no receipt of an ACK) Cheers Frank Kastenholz Atex/EPPS - a Kodak Company All opinions are mine and in no way belong to Atex/EPPS/Kodak (in fact they don't even know that I am saying this) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805171625.AA02847@PTT.LCS.MIT.EDU] <1988051716251500> From: dab@ALLSPICE.LCS.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Proxy ARP (was Re: Dumb vs. smart host routing) Message-ID: <8805171625.AA02847@PTT.LCS.MIT.EDU> Date: 17 May 88 16:25:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Actually, there was one other factor that caused proxy-ARP to lose in that case. This was the use of a default route in the other gateway. It didn't actually know a route to this test subnet I was setting up, it just thought it did (via its default route). So after proxy-ARPing the address I was trying to get to, it forwarded the packet off to the ARPA gateway (its default route), which forwarded the packet off to some random core gateway (its default route) which hopefully dropped it before it became an alligator in Dave Mill's swap. David Bridgham ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3056313@um.cc.umich.edu] <1988051716354600> From: Doug_Nelson@UM.CC.UMICH.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <3056313@um.cc.umich.edu> Date: 17 May 88 16:35:46 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 > As far as I know, "Proxy ARP" only works with subnets, for nodes that > don't know about subnets. In order to send out the ARP request, the > host has to already belive that he can get to the remote host in one > hop. If my machine is on net 128.62, and I want to get to a machine on > net 128.63, I don't send out an ARP request for the machine on net 128.63. > I have to have a route to 128.63 which points to a machine on net 128.62, > and then I'll be ARPing for the machine on 128.62 which is the next hop to > 128.63. Proxy ARP also works in networks where the gateway(s) aren't using any routing protocol at all. We teach many of our systems here that the default route is to themself, with a metric of zero. This forces an ARP for most hosts outside the (sub)network, whether within or outside the full network. It helps that we only have one gateway to the outside world. Doug Nelson, Michigan State University, Computer Lab den@serv1.cl.msu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880517123312.20200323111@v880np.NEWPORT] <1988051717331200> From: BAYNESRT@v880np.NEWPORT Newsgroups: comp.protocols.tcp-ip Subject: Subscription request Message-ID: <880517123312.20200323111@v880np.NEWPORT> Date: 17 May 88 17:33:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 I would like to subscribe to TCP-IP My name/address is: Robert T. Baynes ASECC/TAI (401)841-4249 baynesrt%v880np.decnet@nusc-npt.arpa Thanks for your help. Bob Baynes ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805200427.AA05203@ucbvax.Berkeley.EDU] <1988051717351700> From: cain@EDN-UNIX.ARPA (Edward A. Cain) Newsgroups: comp.protocols.tcp-ip Subject: Re: toothpaste Message-ID: <8805200427.AA05203@ucbvax.Berkeley.EDU> Date: 17 May 88 17:35:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Mike, Please check carefully before using TCP in a tube. The British product is an ointment for piles, not toothpaste. If it's good for both, it's truly an end-to-end product. (heh) The two other TCP products I have, both from England, are the liquid anti-septic and the throat pastilles (lozenges). "For sore throats suck TCP ..." Ed Cain ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805171810.AA19353@chakra.cs.umd.edu] <1988051718105400> From: ogud@CHAKRA.CS.UMD.EDU (Olafur Gudmundsson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet size distribution Message-ID: <8805171810.AA19353@chakra.cs.umd.edu> Date: 17 May 88 18:10:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 > Does anyone have any data on the distribution of packet sizes on an > Ethernet? I have some that shows that most of the traffic is either verry small packets <120 or big >= 1024. The packet size is dependant on type of machines, protcols and usage. The statistics that have been collected here are for large Ethernet with over 100 Ethernet devices 90 of which are WS (all have their own disk). If there is intrest I can post the main results. ____________________________________________________________________________ Olafur Gudmundsson Dept. of Computer Science University of Maryland ARPA: ogud@brillig.umd.edu UUCP: {...!}uunet!mimsy!ogud Tel: (301)-454-6497 (w) UPS: College Park MD. 20742 ATT: (301)-595-4154 (h) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051718240000> Received: from nswses.arpa by SRI-NIC.ARPA with TCP; Wed, 18 May 88 02:31:55 PDT Date: 18 May 88 02:24:00 PST From: "TERVAX::EFBATEY" Subject: Sources V.3.3 / 68020 TCP Stuff To: "tcp-ip" cc: efbatey Reply-To: "TERVAX::EFBATEY" LOOKING FOR TCP SOURCES Add me to the list PLEASE, of those scraping around for legal sources of tcp stuff: telnet, ftp, sendmail ( smtp ), bootp, time, whois, all the other Berk nifties, especially if there is an ice_cubes chance we could port them to our Mot Sys 1131 ( AT&T / Mot(System 1131) Sys V R3.3 for MC68020. We are stuck with the CMC ENP card (VME Bus). Vendor doesn't deliver SMTP / sendmail. We are ATT/MOT Sys V source license holder. ------------------------------------------------------------ | Everett F. Batey II } { UUCP: sun!tsunami!nswed5!efb | | USNSWSES - Code 4V33 } { ARPA: efbatey@NOBBS.UCSB.EDU | | After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA | ------------------------------------------------------------ ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051718570000> Received: from nswses.arpa by SRI-NIC.ARPA with TCP; Wed, 18 May 88 03:14:18 PDT Date: 18 May 88 02:57:00 PST From: "TERVAX::EFBATEY" Subject: *Ethernet* vs *802.3* or whatever ( 1 vs 2 ) To: "tcp-ip" cc: efbatey Reply-To: "TERVAX::EFBATEY" Just got involved with trying to track down interface between HP3000 (MPE_V OS) and my DEC-VMS/SUN/SysV compatible hosts. The Wollongong folks offered me a possible solution which may shed some light on the Common Ethernet ( we most ALL use ) VS *IEEE 802.3*. I can't distinguish between them in my limited understanding. As I come to understand CISCO / cisco offers a bridge which takes E_1 from net_1 and translates the E_1 packets into E_2 packets to resend on net_1, potentially, or on net_2 and vice versa. From this proposition, I infer the E_1 and E_2 packets (1) may coexist on one net but (2) cannot be substituted directly for each other. Would someone like to further enlighten me? ------------------------------------------------------------ | Everett F. Batey II } { UUCP: sun!tsunami!nswed5!efb | | USNSWSES - Code 4V33 } { ARPA: efbatey@NOBBS.UCSB.EDU | | After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA | ------------------------------------------------------------ ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805181758.AA24859@ucbvax.Berkeley.EDU] <1988051720025700> From: cire@clash.cisco.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <8805181758.AA24859@ucbvax.Berkeley.EDU> Date: 17 May 88 20:02:57 GMT References: <8805150047.AA04159@BITSY.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 >> Date: Sat, 14 May 88 20:47:14 EDT >> From: Jeffrey I. Schiller >> To: KASTEN@MITVMA.MIT.EDU >> Cc: jqj@HOGG.CC.UOREGON.EDU, tcp-ip@SRI-NIC.ARPA >> Subject: Re: Dumb vs. smart host routing >> >> ... >> >> simplified the question from "Who can route to network X?" to just a >> simple request for a default router. That router can then send >> redirects later when packets arrive.] >> >> -Jeff A reasonable idea. It still requires the hosts involved to implement some kind of redundancy mechanism if the default router goes down. But it would not have to know about routing just that it needs to find a new default. -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805181444.AA21740@ucbvax.Berkeley.EDU] <1988051720120000> From: yurcik@NRL-LCP.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Washington DC Area ACM-SIGCOMM Meeting 6/17 Message-ID: <8805181444.AA21740@ucbvax.Berkeley.EDU> Date: 17 May 88 20:12:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The Internet Lines: 111 As a result of the responses from Redskins Fans from all over... ******************************************************************************* WASHINGTON DC SIGCOMM Association for Computing Machinery Washington, D.C. Chapter Special Interest Group on Data Communications NETWORK ROUNDTABLE #2 Topic : "NETWORK MANAGEMENT" ============================== DATE: Friday, June 17, 1988 TIME: 1:00 p.m. to 5:00 p.m. PLACE: Naval Research Laboratory Building 222 Auditorium Washington D.C. 20375-5000 RESERVATIONS: RSVP *ONLY* with Ms. Kelly Short 8:00AM-3:30PM, (202) 767-3887 If Ms. Short is unavailable please call back since she is the only maintainer of the list. All attendees must RSVP by June 10th because names must be left at the guard posts for entry onto the base. For security reasons, non-U.S. citizens and foreign nationals might not be able to attend if special arrangements are not made in advance. For additional information, contact Bill Yurcik, "yurcik@nrl-lcp.arpa" or (202) 767-3903. DIRECTIONS: Carpooling advised due to parking limitations. Located just off Interstate 295 near the Capitol Beltway (I-95) and the Wilson Bridge on the Maryland Shoreline of the Potomac River. Signs off I-295 clearly mark the Laboratory exits from the north and south. Following is directions to the North Gate of NRL which is the closest gate to Building 222. FROM THE SOUTH: Take the Capitol Beltway to Maryland exit 2 (I-295 North) on the Maryland side of the Wilson Bridge. From I-295 take exit 1 (NRL), turn right at the first light onto Overlook Avenue and then make a left at the next light onto Chesapeake Street. Proceed slowly with a 15 mph monitored speed limit. Stop at the outer guard house and identify yourself as attending a meeting at NRL. Continue past 2 more stop signs, stop at the NRL guard post and identify yourself by your RSVP name and ask directions if needed. Bldg. 222 is directly on your left past the gate but parking may be best available by bearing right and parking along the river. FROM THE NORTH: Take the Capitol Beltway to Maryland exit 22B, (BW Parkway/I-295 South) and follow I-295 past New York Avenue and Bolling Air Force Base. Take exit 1 (NRL), proceeeding straight past one light, and turn right at the 2nd light onto Chesapeake Street. Note that Chesapeake Street has a 15 mph monitored speed limit. Stop at the outer guard house and identify yourself as attending a meeting at NRL. Continue past 2 more stop signs, stop at the NRL guard post to identify yourself by your RSVP name and ask directions if needed. Bldg. 222 is directly on your left past the gate but parking may be best available by bearing right and parking along the river. DRAFT AGENDA PROGRAM: 1:00-1:10 Greeting/Introduction B. Yurcik/ACM member E. Gardner/SIGCOMM,Chair GUEST SPEAKER: 1:10-2:00 Keynote Address V. Cerf/Corporation for VINT CERF "Network Management" National Research Initiative/ National Chair ACM SIGCOMM 2:00-2:20 Break ROUNDTABLES: Area facility network architects, managers, and implementors will have an opportunity to share experiences and discuss technology issues in response to prepared questions and open questions from the audience. 2:20-3:15 Roundtable - "Network Management and the Internet" (Moderated by Vint Cerf) Corporation for Open Systems - Howard Berkowitz NSF - unnamed Proteon - unnamed SURANET - Jack Hahn Vitalink Corp. - Tim Lee-Thorpe University of Maryland - Mike Petry 3:20-5:00 Roundtable - "Network Management and the Campus LAN" (Moderated by Walt Roehr, Executive Telecommunication Networks) Cisco Corp. - unnamed DEC - unnamed IBM - unnamed NASA Goddard - J. Pat Gary National Bureau of Standards - Craig Hunt Naval Research Laboratory - Mac Mcculloch/Bill Fink ******************************************************************************** ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2925@emory.uucp] <1988051800481200> From: km@emory.uucp (Ken Mandelberg) Newsgroups: comp.periphs,comp.lang.postscript,comp.protocols.tcp-ip Subject: Postscript Printers with ethernet interface? Keywords: tcp Message-ID: <2925@emory.uucp> Date: 18 May 88 00:48:12 GMT Organization: Math & Computer Science, Emory University, Atlanta Lines: 9 The only Postscript (or clone) laserprinters I know that has an ethernet tcp/ip interface are by Imagen. Does anyone know of any others? (Dec's DECNET printers don't count). -- Ken Mandelberg | {decvax,sun!sunatl,gatech}!emory!km UUCP Emory University | km@emory BITNET Dept of Math and CS | km@emory.ARPA ARPA,CSNET Atlanta, GA 30322 | Phone: (404) 727-7963 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [18947@watmath.waterloo.edu] <1988051801150700> From: magreer@grand.waterloo.edu (Mark Greer) Newsgroups: comp.protocols.tcp-ip Subject: Compile of Transport protocols Keywords: transport,protocols Message-ID: <18947@watmath.waterloo.edu> Date: 18 May 88 01:15:07 GMT Sender: daemon@watmath.waterloo.edu Distribution: comp Lines: 12 Hello everyone, I was wondering if I could impose on you for a few moments? I'd like to compile a list of all the transport level protocols that anyone can think of that have some sort of formal description. First ones that come to mind are TCP (of course), ISO, VMTP, RDP, NetBLT ... What else is there? Thanks in advance! Mark P.S. Please ***MAIL*** replies directly to me (I'll post a summary), thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [18949@watmath.waterloo.edu] <1988051801190600> From: magreer@grand.waterloo.edu (Mark Greer) Newsgroups: comp.protocols.tcp-ip Subject: Compile of Transport protocols Keywords: transport,protocols Message-ID: <18949@watmath.waterloo.edu> Date: 18 May 88 01:19:06 GMT Sender: daemon@watmath.waterloo.edu Distribution: comp Lines: 21 Oops, I forgot to give my address. I'll post the message again... > Hello everyone, I was wondering if I could impose on you for a > few moments? I'd like to compile a list of all the transport level > protocols that anyone can think of that have some sort of formal > description. First ones that come to mind are TCP (of course), ISO, > VMTP, RDP, NetBLT ... What else is there? Thanks in advance! > > Mark > > P.S. Please ***MAIL*** replies directly to me (I'll post a summary), > thanks. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Greer magreer@grand.waterloo.edu University of Waterloo magreer@grand.waterloo.cdn Waterloo, Ontario magreer@grand.uwaterloo.ca Canada {network backbone}!watmath!grand!magreer ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4115@killer.UUCP] <1988051801235400> From: jdp@killer.UUCP (Jim Pritchett) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc,comp.sys.dec Subject: DECNET vs. tcp-ip? Keywords: DECNET tcp-ip Silicon Graphics DEC Iris VMS Message-ID: <4115@killer.UUCP> Date: 18 May 88 01:23:54 GMT Organization: The Unix(R) Connection, Dallas, Texas Lines: 28 Hello, I am posting this request for a friend without net.access. Please respond by Email since I dont usually frequent all of the newsgroups on this message. Could someone out there please provide me with a list of the relevant pros and cons of using DECNET vs. tcp-ip? The current hardware involved is a VAX 8800 network (DECNET), some MicroVAXen, and (the new part!) several Silicon Graphics Iris workstations. Naturally, the SG machines run their version of Unix, while the DEC machines are running VMS. Please start with a general comparison of the two protocols before discussing the specific hardware in question. Other, very different hardware may/will be added in the future, so we would like to have more info. Please respond by Email. Thanks, Jim Pritchett PS. Please, no flames about how dumb/impossible it is to use DECNET on a Unix machine. We have been told that a third party can make this run for us if we want it. (Sorry, but I dont have any more info on this.) I dont know whether the Iris really can run DECNET, I am just relaying the request. Again, thank you for your help in this matter. ~. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051806200200> Received: from MITVMA.MIT.EDU by SRI-NIC.ARPA with TCP; Wed, 18 May 88 07:39:52 PDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 9860; Wed, 18 May 88 10:37:40 EDT Received: by MITVMA (Mailer X1.25) id 9858; Wed, 18 May 88 10:37:39 EDT Date: Wed, 18 May 88 10:20:02 EDT From: Frank Kastenholz Subject: Re: hosts and gateways and protocols To: Greg Minshall Cc: tcp-ip@sri-nic.arpa In-Reply-To: Your message of Mon, 16 May 88 10:55:57 pdt >What my tendancy has been is to allow for the specification of a default >router (yes, just one). If the router isn't specified, then we listen >for RIP broadcasts. Now, I never know what is INSIDE a RIP packet. However, >I choose a default router based on the largest RIP packet seen, and I stay >with that router for five minutes or so. So, if I continue getting RIP >packets, then I keep following routers. This assumes that your host can understand that the packet is a RIP packet. If my routers use another IGP then the hosts will not know that it is an IGP packet so they can not "backtrack" to the source of the packet and get a router. >I also feel for those souls whose routers occasionally crash, and who would >like routes to switch automatically. I don't believe that just because >you need this capability once per day that should exclude it from being >automated. Unfortunately I must strongly disagree with the last sentence. TCP/IP is entering the non-technical world very rapidly. The company that I work for makes large editorial systems for newspapers - lets reporters and ad takers enter their material, editors edit it, layout people design and build the pages and then output the whole thing to a photo typesetter. Newspaper people (reporters/editors/etc) know next to nothing about networking and we can't really teach them. This model is valid in more and more networks. the failure recovery mechanism MUST BE AUTOMATIC. The recovery mechanism is required for a very simple reason - money. If a newspaper doesn't go to press because the network broke then the paper does not realize its advertising revenues - and that is the name of the game for all of the "commercial" TCP/IP sites. I think that the idea of using multicasts/broadcasts is better than the query/response model. It lets the hosts detect a gateway failure before they go through a few retransmissions wasting resources (assuming that the hosts are reasonably intelligent). The only possible problem is that there may be networks with many gateways and the "I am a gateway" traffic could get to be burdensome (especially for small hosts that can't handle many packets per second - e.g. PC's). Perhaps using an Ethernet multicast address (for Ethernet networks) would be the way to go - it could let small hosts filter out the unwanted traffic. If this is done, though, a query/response mechanism may also be needed. Cheers Frank Kastenholz EPPS Inc - a Kodak Company All opinions are mine........ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051806420000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed, 18 May 88 07:45:14 PDT Date: 18 May 1988 10:42-EDT Sender: GBELING@A.ISI.EDU Subject: more about TCP From: GBELING@A.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]18-May-88 10:42:59.GBELING> hello, here in good old europe you do not only find toothpaste but also really hardware: just in front of me on my desk there is a little box with a power connection, a switch and a red lamp which precipitates a little heat: that is a real internet instrument from the time when Khanyards tried to repair cerfbords in order to keep single packet-steamers moving. this instrument is nothing else than a soldering iron which calls itself TCP but to the hell i do not know why. (german manufacturer) may be darpa should found a museum with little things like this so that people at the year 2000 remember what networking is. regards gerd beling ----MESSAGE-END---- ----MESSAGE-BEGIN---- [226@quick.COM] <1988051808151900> From: srg@quick.COM (Spencer Garrett) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <226@quick.COM> Date: 18 May 88 08:15:19 GMT References: <8805140446.AA04773@ucbvax.Berkeley.EDU> Organization: Quicksilver Engineering, Seattle Lines: 3 Why can't a host just ARP for any destination and expect the appropriate gateway(s) to answer? If there were a hopcount field in the ARP record, I think this would solve all the problems. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051809213500> Received: from ccd.bbn.com ([8.3.0.2]) by SRI-NIC.ARPA with TCP; Wed, 18 May 88 10:24:01 PDT Date: Wed, 18 May 88 13:21:35 EDT From: "Drew M. Powles" Subject: connecting Internets? To: tcp-ip@sri-nic.arpa Cc: dpowles@ccd.bbn.com Has any thought been given to the mechanisms and methodologies to be used for interconnecting separate Internets with overlapping address spaces? Granted, there's only one Internet at the moment, and we be it, but there may come a time where more than one Internet springs up along side of the existing Internet, even in the DoD, with completely separate administration mechanisms, including address assignment (although still based on the internetworking protocols of choice at the time, whether that's DoD IP, or ISO IP down the road). And these side-by-side Internets may have some interoperability requirements. Can interoperability be successfully implemented at an Internet (or read Level 3) position in the protocol stack, or do we have to resort to some application level funniness? I know this may seem to be a silly or somewhat naive question, but there are actual situations where this could eventually arise. Any thoughts? many thanks, dmp dpowles@bbn.com Drew M. Powles BBN Communications 9810 Patuxent Woods Drive Columbia, MD 21046 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805230313.AA09518@ucbvax.Berkeley.EDU] <1988051810240000> From: efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY") Newsgroups: comp.protocols.tcp-ip Subject: Sources V.3.3 / 68020 TCP Stuff Message-ID: <8805230313.AA09518@ucbvax.Berkeley.EDU> Date: 18 May 88 10:24:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "TERVAX::EFBATEY" Organization: The Internet Lines: 19 LOOKING FOR TCP SOURCES Add me to the list PLEASE, of those scraping around for legal sources of tcp stuff: telnet, ftp, sendmail ( smtp ), bootp, time, whois, all the other Berk nifties, especially if there is an ice_cubes chance we could port them to our Mot Sys 1131 ( AT&T / Mot(System 1131) Sys V R3.3 for MC68020. We are stuck with the CMC ENP card (VME Bus). Vendor doesn't deliver SMTP / sendmail. We are ATT/MOT Sys V source license holder. ------------------------------------------------------------ | Everett F. Batey II } { UUCP: sun!tsunami!nswed5!efb | | USNSWSES - Code 4V33 } { ARPA: efbatey@NOBBS.UCSB.EDU | | After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA | ------------------------------------------------------------ ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805190845.AA10947@ucbvax.Berkeley.EDU] <1988051810570000> From: efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY") Newsgroups: comp.protocols.tcp-ip Subject: *Ethernet* vs *802.3* or whatever ( 1 vs 2 ) Message-ID: <8805190845.AA10947@ucbvax.Berkeley.EDU> Date: 18 May 88 10:57:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "TERVAX::EFBATEY" Organization: The Internet Lines: 25 Just got involved with trying to track down interface between HP3000 (MPE_V OS) and my DEC-VMS/SUN/SysV compatible hosts. The Wollongong folks offered me a possible solution which may shed some light on the Common Ethernet ( we most ALL use ) VS *IEEE 802.3*. I can't distinguish between them in my limited understanding. As I come to understand CISCO / cisco offers a bridge which takes E_1 from net_1 and translates the E_1 packets into E_2 packets to resend on net_1, potentially, or on net_2 and vice versa. From this proposition, I infer the E_1 and E_2 packets (1) may coexist on one net but (2) cannot be substituted directly for each other. Would someone like to further enlighten me? ------------------------------------------------------------ | Everett F. Batey II } { UUCP: sun!tsunami!nswed5!efb | | USNSWSES - Code 4V33 } { ARPA: efbatey@NOBBS.UCSB.EDU | | After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA | ------------------------------------------------------------ ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805180903.aa03398@CAD.USNA.MIL] <1988051813034800> From: tsmith@USNA.MIL ("Tim G. Smith", Mechanical) Newsgroups: comp.protocols.tcp-ip Subject: SendMail Message-ID: <8805180903.aa03398@CAD.USNA.MIL> Date: 18 May 88 13:03:48 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 222 This is a long message. If your aren't interested in sendmail and large networks then you might as well skip this message. You may have seen this message elsewhere as it is being cross posted to big-lan, sun-spots, nfs, tcp-ip, and unix-wizards. If there is a more appropriate list to discuss this in let me know and I will take this matter there. We here at the US Naval Academy (USNA) in Annapolis, MD are building a network. We have been operating an ethernet LAN connecting several minis and workstations for quite some time. We use thin, thick, and fiber based ethernet. We are reasonably well versed in TCP/IP and have experience with mpr's and gateways. Our hosts run the gamut from Zenith PC AT clones using SUNs PCNFS package to SUN workstations to VAX and Gould minis. We have about 20 hosts on our network that are capable of exchanging mail via sendmail. We are in a growth process and expect our number of workstations to increase dramatically as our new network is installed and more folks buy workstations. It is quite possible that we will eventually have 4-7k workstations and their servers attached to our network in the future. We currently use MMDF as our mail handler but are in the process of switching to sendmail as sendmail seems to be emerging as the "standard" mail handler. I have been selected to work on installing sendmail and planning our mail routing system. I have spent a reasonable amount of time working with sendmail and thought I would ask around to see if what everyone else is doing. Here is what I am planning/doing.... Some background... First, USNA will switch from 2 level domains to 3 level. Currently hostnames are of the form "machine.USNA.MIL", in the near future hostnames will change to the form "machine.division.USNA.MIL" (if necessary we might even switch to 4 level domains- "machine.department.division.USNA.MIL"). There will be an authoritative host named USNA.MIL. There will also be a host (or possibly an alias pointing to a host) for each sub-domain, ie there will be a sub-domain named "math.USNA.MIL" with a primary server named "math.USNA.MIL". Second, every user's home directory will be made available to him on every workstation in the yard. The goal is to allow any user to sit down in front of any workstation in the yard and be able to login and have his files available. Yes, I realize that will involve a tremendous amount of NFS cross mounts and may not actually be feasible but that is the plan for the time being. How the password file updates will be made has not yet been determined. Ideally I would like to use SUN's Yellow Pages to handle all of the password mess. I am not sure how may vendors do/will support YP but I will worry about that problem later. I have come up with the following tenets that I think are wise. If you disagree then send me mail and we can discuss it- maybe we all can learn something new about sendmail. I would prefer that all responses come straight to me and I will summarize to the net if there is interest. Maybe there is enough interest to start a sendmail interest group (provided there isn't already one that I don't know about). Sendmail workstation/server configuration philosophy: (aka "the gospel according to tim") ------------------------------------------------------- -All mail should live on a sub-domain host. Individual workstations should never receive incoming mail- there WILL NOT be a mailer daemon running on the workstation to receive incoming mail. Whether mail will live in /usr/spool/mail or the user's home directory is yet to be decided. I am leaning towards hacking sendmail to put mail in the user's home directory. -Workstations punt all mail to their sub-domain server. Workstations exchange mail only with their sub-domain server. Only outgoing mail is handled by workstations. -Workstations should have very minimal configuration files on them. Workstations should have a sendmail.cf that is virtually identical to all others in the yard. Workstation sendmail.cf's should essentially be "maintenance free". -The address data in intra-USNA messages will never contain a workstation hostname- only sub-domain names will be used. (There will be a host or host alias with the sub-domain name.) -Inter-sub-domain mail (ie intra-USNA) can be directly routed from one sub-domain server to another. -Mail bound for destinations outside USNA will be routed from the sub-domain host to the USNA.MIL server. This mail will have USNA.MIL in the address lines. Sub-domain names will never appear in outgoing message address lines. This will allow USNA.MIL to reliably accept mail from the outside world regardless of the status of the internal USNA network. -Mail arriving at USNA.MIL from outside hosts will be forwarded to the proper server using a large central data base of aliases on the USNA.MIL server. Individual users will also be able to forward their mail via the .forward file in their home directory. ---------- End of Philosophy Statement-------------------- Here is a typical scenario that I imagine... User "joe" invokes the sending front end to sendmail on his workstation. He composes and addresses a message to user "mike" and hands it to his mail agent to pass to sendmail. Sendmail on the local workstation starts up and the following takes place: 1) The workstation punts the message to the sub-domain server. 2) The sub-domain server tries to deliver the mail. If the sub-domain-server finds that "mike" is a user who gets his mail on this server then the mail is delivered as per sendmail's local mail delivery procedures. If the sub-domain-server finds that "mike" is a user who gets his mail on another sub-domain-server then the mail is passed to that server. If the local sub-domain-server cannot determine where "mike" gets his mail then the message is punted to USNA.MIL (the next level up the domain ladder). 3) USNA.MIL gets the mail and tries to deliver it. If USNA.MIL knows who the user is the mail will get delivered- if USNA.MIL doesn't know who the user is then that user doesn't exist and an error should be returned to the sender. What needs to be done to make all this happen is not yet known. SUN's Yellow Pages service either complicates or simplifies this whole issue. Do we expect all the machines in the yard to understand YP (it would sure be nice if they did!)? I doubt that I can count on all of the yard understanding YP. I am open to suggestions/opinions, one way or another. ------------------------------------------------------------ Problems I for see: -All sorts of "odd" cases... A user could be logged into a workstation in a division other than his own sending mail to anyone. Not a major problem but something to keep in mind when "Reply-To:" and "From:" lines are being set up. What should the "Reply-To:" and "From:" lines say? Should they list the sub-domain server that the user is sending from? Should they list the user's "home" sub-domain? (I would tend think so.) If the mail is addressed to someone outside of USNA then the problem will go away since (according to the tenets above) all mail leaving USNA should have its "Reply-To:" and "From:" fields rewritten to the form "user@USNA.MIL". A user may prefer to receive his mail on a machine other than his "home" sub-domain server. No big deal, a .forward file should handle this without any problems (I think). Where do aliases get expanded? I have just about ruled out an alias expansion on each workstation. I would think that they could be expanded on either the sub-domain server or on USNA.MIL (or maybe on both). -Conflicts over file locking and simultaneous access to the user's mailbox. Here is a possible scenario of locking problems... User "joe" is reading his mail on workstation "xxx.math.USNA.MIL". joe's workstation is diskless and mounts its files from his sub-domain server. In order for this to happen the directory that joe's mailbox lives in will have to be NFS mounted on his workstation. For joe to be able to delete messages from his mailbox he will need write permissions on his mailbox. Thus the NFS mount of the directory containing joe's mailbox will have to be mode "rw". I see a potential problem here. If joe is has just finished deleting messages from his mailbox and is updating it when a new message comes in (ie math.USNA.MIL tries to deliver it) there could be an ugly scene as the process trying to purge the deleted messages from the mailbox and the delivering agent fight over who gets to write in the mailbox file. So what happens in the above case? -Where do users mailboxes live? If I already have all sorts of home directories NFS cross-mounted all over the place I certainly don't want to add to the mess by cross mounting /usr/spool/mail all over. Not to mention what do I call the directories? I would be NFS mounting several different /usr/spool/mail directories from several different servers. I have already ruled out the idea of a single machine with a massive /usr/spool/mail for several reasons. Ideally I would like to have each user's mailbox live in his home directory. -------------------------------------------------- Sendmail Gripes: -sendmail.cf cannot find out its domain (or subdomain) internally (at least I can't figure out a way to do this). This would be a nice feature to have so we don't have to hard code this info into each sendmail.cf. (Isn't there a system call that returns the domain name of a host? How about adding an internal macro to sendmail to add this feature.) -It should be possible to configure sendmail to have the user's mailbox live anywhere (Like maybe their home directory). Well that is about it. I would like to hear from others- sendmail experiences, solutions to my problems, ideas about what to do next, or just commiseration would all be appreciated. NOTE: I LIKE SENDMAIL! I think it is very flexible and powerful. I am simply pointing out my difficulties (and non-difficulties) and asking whatcha'all think. So please spare me any flames telling me I don't appreciate sendmail and that I should be condemned to an afterlife in a post office in hell doing "manual mail routing". OK? Looking forward to hearing from everybody, Tim Smith US mail:CADIG mailstop: 11G E-mail: US Naval Academy internet:tsmith@USNA.MIL Annapolis, MD 21402 uucp :...!uunet!usna!tsmith MaBell :(301)267-4413 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805210016.AA08227@ucbvax.Berkeley.EDU] <1988051814200200> From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) Newsgroups: comp.protocols.tcp-ip Subject: Re: hosts and gateways and protocols Message-ID: <8805210016.AA08227@ucbvax.Berkeley.EDU> Date: 18 May 88 14:20:02 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 47 >What my tendancy has been is to allow for the specification of a default >router (yes, just one). If the router isn't specified, then we listen >for RIP broadcasts. Now, I never know what is INSIDE a RIP packet. However, >I choose a default router based on the largest RIP packet seen, and I stay >with that router for five minutes or so. So, if I continue getting RIP >packets, then I keep following routers. This assumes that your host can understand that the packet is a RIP packet. If my routers use another IGP then the hosts will not know that it is an IGP packet so they can not "backtrack" to the source of the packet and get a router. >I also feel for those souls whose routers occasionally crash, and who would >like routes to switch automatically. I don't believe that just because >you need this capability once per day that should exclude it from being >automated. Unfortunately I must strongly disagree with the last sentence. TCP/IP is entering the non-technical world very rapidly. The company that I work for makes large editorial systems for newspapers - lets reporters and ad takers enter their material, editors edit it, layout people design and build the pages and then output the whole thing to a photo typesetter. Newspaper people (reporters/editors/etc) know next to nothing about networking and we can't really teach them. This model is valid in more and more networks. the failure recovery mechanism MUST BE AUTOMATIC. The recovery mechanism is required for a very simple reason - money. If a newspaper doesn't go to press because the network broke then the paper does not realize its advertising revenues - and that is the name of the game for all of the "commercial" TCP/IP sites. I think that the idea of using multicasts/broadcasts is better than the query/response model. It lets the hosts detect a gateway failure before they go through a few retransmissions wasting resources (assuming that the hosts are reasonably intelligent). The only possible problem is that there may be networks with many gateways and the "I am a gateway" traffic could get to be burdensome (especially for small hosts that can't handle many packets per second - e.g. PC's). Perhaps using an Ethernet multicast address (for Ethernet networks) would be the way to go - it could let small hosts filter out the unwanted traffic. If this is done, though, a query/response mechanism may also be needed. Cheers Frank Kastenholz EPPS Inc - a Kodak Company All opinions are mine........ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [193@ftp.COM] <1988051814275600> From: nancy@ftp.COM (Nancy Connor) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP in the UK Message-ID: <193@ftp.COM> Date: 18 May 88 14:27:56 GMT References: <880516153824.20600B3D081@nssdca.GSFC.NASA.GOV> Organization: FTP Software Inc., Cambridge, MA Lines: 13 In-reply-to: PETERS@nssdca.GSFC.NASA.GOV's message of 16 May 88 20:38:24 GMT Posting-Front-End: GNU Emacs 18.47.2 of Thu Aug 13 1987 on ftp (berkeley-unix) I recently returned from a year in the United Kingdom where quite often I would notice large signs saying "TCP AOK". Rather than attempting to sell new implementations of TCP/IP for your favourite BBC micro, the adverts were for a topological disinfectant of some sort. I wonder if the active ingredient was that same TCP petrol additive... Actually, I think that's TSP (tri-sodium phosphate)... it's used to clean floors and walls and such. -Nancy Connor FTP Software nancy@ftp.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]18-May-88.10:42:59.GBELING] <1988051814420000> From: GBELING@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: more about TCP Message-ID: <[A.ISI.EDU]18-May-88.10:42:59.GBELING> Date: 18 May 88 14:42:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 hello, here in good old europe you do not only find toothpaste but also really hardware: just in front of me on my desk there is a little box with a power connection, a switch and a red lamp which precipitates a little heat: that is a real internet instrument from the time when Khanyards tried to repair cerfbords in order to keep single packet-steamers moving. this instrument is nothing else than a soldering iron which calls itself TCP but to the hell i do not know why. (german manufacturer) may be darpa should found a museum with little things like this so that people at the year 2000 remember what networking is. regards gerd beling ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805230505.AA10784@ucbvax.Berkeley.EDU] <1988051817213500> From: dpowles@CCD.BBN.COM ("Drew M. Powles") Newsgroups: comp.protocols.tcp-ip Subject: connecting Internets? Message-ID: <8805230505.AA10784@ucbvax.Berkeley.EDU> Date: 18 May 88 17:21:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 Has any thought been given to the mechanisms and methodologies to be used for interconnecting separate Internets with overlapping address spaces? Granted, there's only one Internet at the moment, and we be it, but there may come a time where more than one Internet springs up along side of the existing Internet, even in the DoD, with completely separate administration mechanisms, including address assignment (although still based on the internetworking protocols of choice at the time, whether that's DoD IP, or ISO IP down the road). And these side-by-side Internets may have some interoperability requirements. Can interoperability be successfully implemented at an Internet (or read Level 3) position in the protocol stack, or do we have to resort to some application level funniness? I know this may seem to be a silly or somewhat naive question, but there are actual situations where this could eventually arise. Any thoughts? many thanks, dmp dpowles@bbn.com Drew M. Powles BBN Communications 9810 Patuxent Woods Drive Columbia, MD 21046 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [886@kaos.UUCP] <1988051817385400> From: romkey@kaos.UUCP (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: Re: hosts and gateways and protocols Message-ID: <886@kaos.UUCP> Date: 18 May 88 17:38:54 GMT References: <8805161802.AA15658@mtxinu.UUCP> Reply-To: romkey@kaos.UUCP (John Romkey) Organization: Chaos; Somerville, MA Lines: 25 In article <8805161802.AA15658@mtxinu.UUCP> minshall@kinetics.UUCP (Greg Minshall) writes: >Right now, listening for RIP packets is, in many environments, the best way >to locate potential gateways. There is no reason this needs to have a >separate process listening - consider these packets to be like ICMP packets. Many PC's that are out on the Internet right now aren't on the Internet full time. They're running TCP on demand - when user wants to telnet, then they're active on the net and the rest of the time they're deaf dumb and blind. >Third, I'm not sure that every time TCP retransmits a packet I want to >have to revalidate the route. I don't think TCP should revalidate the route every time it retransmits. I think it should when it's decided it's in trouble. Which should be, perhaps, when it's noticed that the round trip delay has been going up steadily or that it's half of the way to deciding the connection is dead. These are just suggestions, I don't have any definite heuristics for it. If I were writing another IP and TCP implementaiton I'd probably try to put something like this in it and experiment with it, but I'm not right now, so I'm not really sure exactly what conditions to do it under. -- - john romkey UUCP: romkey@kaos.uucp ARPA: romkey@xx.lcs.mit.edu ...harvard!spdcc!kaos!romkey Telephone: (617) 776-3121 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [887@kaos.UUCP] <1988051817420400> From: romkey@kaos.UUCP (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: Re: Proxy ARP (was Re: Dumb vs. smart host routing) Message-ID: <887@kaos.UUCP> Date: 18 May 88 17:42:04 GMT References: <8805170444.AA20271@Larry.McRCIM.McGill.EDU> Reply-To: romkey@kaos.UUCP (John Romkey) Organization: Chaos; Somerville, MA Lines: 18 In article <8805170444.AA20271@Larry.McRCIM.McGill.EDU> philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) writes: >But you should be able to configure a router to not know about a >network, and therefore not answer requests about it (to `unknow' >the network, as it were). If you can't do this, it reflects a >flaw in the implementation, not the protocol. > >-Philip Suppose I don't own and run all the routers. Suppose the university or corporate telecommunications office does, or suppose BBN runs one of them, or the company down the street. I don't necessarily have control over all the computers on my network, and the level of effort needed to go through to get the necessary changes done to some of them for 15 minutes of testing may be prohibitive. -- - john romkey UUCP: romkey@kaos.uucp ARPA: romkey@xx.lcs.mit.edu ...harvard!spdcc!kaos!romkey Telephone: (617) 776-3121 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5597@cup.portal.com] <1988051818473900> From: David_J_Buerger@cup.portal.com Newsgroups: comp.periphs,comp.lang.postscript,comp.protocols.tcp-ip Subject: Re: Postscript Printers with ethernet interface? Message-ID: <5597@cup.portal.com> Date: 18 May 88 18:47:39 GMT References: <2925@emory.uucp> Distribution: na Organization: The Portal System (TM) Lines: 11 XPortal-User-Id: 1.1001.1820 I understand that Talaris has a printer that can act as an Ethernet node. They have a PostScript upgrade module for that printer in beta, which should be released in a few months. Call them for more info. at 619/587-0787. Standard disclaimer... David Buerger dbuerger@scu.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5503@potomac.ads.com] <1988051819551700> From: jtn@potomac.ads.com (John T. Nelson) Newsgroups: comp.sys.ibm.pc,comp.protocols.tcp-ip Subject: Need info on Ethernet products for the IBM AT and Sun Message-ID: <5503@potomac.ads.com> Date: 18 May 88 19:55:17 GMT Organization: Advanced Decision Systems, Arlington VA Lines: 30 We would like to network our IBM AT to one of our Sun Microsystems computers. The ideal method is to just plug the AT into the Sun's ethernet network using an add--on ethernet interface card. Someone recommended the Western Digital Ethercard for this purpose. But what kind of software is available for the IBM AT that will let me communicate with Suns? We would like to do basic things like file transfer, finger, telnet and maybe hardcopy on the Sun from the AT if that can be done. Recommendations? Would TOPS for the AT provide anything that I need? TOPS would have to be run on the Sun I suppose and that's probably expensive. Are there hardware interfaces for the AT that will let me communicate with Appletalk (well there must be since people do connect ATs to Appletalk)? -- John T. Nelson UUCP: sun!sundc!potomac!jtn Advanced Decision Systems Internet: jtn@potomac.ads.com 1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611 Cherish Conserve Consider Create ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805182101.AA03068@flora.wustl.edu] <1988051821012300> From: guru@FLORA.WUSTL.EDU (Gurudatta Parulkar) Newsgroups: comp.protocols.tcp-ip Subject: Re: Davidson's book vs. Comer's book Message-ID: <8805182101.AA03068@flora.wustl.edu> Date: 18 May 88 21:01:23 GMT References: <8805170455.AA20399@Larry.McRCIM.McGill.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 >>is why I turned to Comer's book. Comer's book is MUCH better although some >>of the chapters (specifically those dealing with routing) didn't feel rig >> [Stuff Deleted] >No, I felt the same way. The chapter on routing is too brief and left [Stuff Deleted] I enjoyed Doug's book also, and thought the "Hints to Implementors" was a great idea (there should be a 10 Most Deadly Sins RFC [like don't [Stuff Deleted] This spring, I used Doug's book as a supplementary text for a computer networking course (I had a prepublished version) with Stallings book as the main text. As a supplementary text, it turned out excellent as students understood the ARPA internet protocols well. However, I am still not sure if it will be a satisfactory text by itself for a course because of its lack of treatment of fundamental networking principles, lack of good exercises, and its treatment of only TCP/IP. Is anybody planning to use it as the sole text for a course ? -guru Dr. Guru Parulkar Asst Professor guru@flora.wustl.edu Dept of Computer Science parulkar@udel.edu Washington University wucs1!guru@uunet.uu.net St. Louis MO 63130 (314) 889-4621 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [May.18.18.59.58.1988.25057@athos.rutgers.edu] <1988051823000200> From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: finding routes Message-ID: Date: 18 May 88 23:00:02 GMT References: <8805102321.AA26819@hogg.cc.uoregon.edu> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 50 I agree in theory that hosts shouldn't know anything about routing. However I find that in practice, BSD-derived implementations make it hard to carry that out. Other implementations seem to have similar problems as well, but I know BSD the best. The simplest approach is to set a default route for a nearby gateway and depend upon it for redirects. The problem is, what if one of of the gateways goes down. There is no way to get a crashed gateway to redirect you back to the default, nor is there any way to handle a default gateway going down. However if you are more concerned with lines going down than gateways going down, that's a reasonable alternative. This is under 4.2. Under 4.3, routes will be declared down if a TCP connection is about to time out. This means that routing will return to the default. Theoretically I suspect one could specify several defaults, and if the first one goes down another one would be tried, but I haven't verified that. Our problem is that this only works for TCP. NFS doesn't talk to the routing layer, so if you have a path that is used only by NFS, and the route goes down, you lose. We are currently using a default with a metric of 0. This is effect makes our machines treat everything as local, and issue ARP's for everything. Since our gateways do proxy ARP, that works. However even this has a problem: ARP entries time out if they aren't used, but if somebody keeps retrying something, a bad ARP entry will stay there forever. In my view, 4.3 has made enough improvements that the default gateway approach is probalby better for 4.3-based code, while the proxy ARP approach is probalby better for 4.2-based code. But none of the approaches is a complete solution. Running RIP in passive mode sounds like it would be a complete solution, if your gateways run RIP. However it is going to create performance problems for networks with lots of diskless nodes. That's because when a packet arrives, all your workstations will have to swap in their copy of routed, and so you'll have lots of synchronized network traffic, which will likely saturate your network. I understand that a subcommittee of the IETF is working on this problem, and plans to add one or two new ICMP types. Unfortunately, this is likely to take several years to make it through the vendors (some of whom don't even do subnets yet). This is probably the biggest disadvantage of TCP/IP. It seems to take someone with a reasonable knowledge of routing to set up a network and add hosts to it. This contrasts with DECnet, where about all you have to do is set the DECnet address, and routing is handled automatically. I regard TCP/IP as a better protocol for larger networks, and the newer TCP/IP routing technology as better than DECnet phase IV (but probably not phase V). But I have to say that TCP/IP networks of small or moderate size appear to be harder to set up and to diagnose routing problems in. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [May.18.19.06.57.1988.25101@athos.rutgers.edu] <1988051823065900> From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: 802 (.2).3 TCP/IP Keywords: interoperability? Message-ID: Date: 18 May 88 23:06:59 GMT References: <1919@ssc-vax.UUCP> <1080@thumper.bellcore.com> Distribution: na Organization: Rutgers Univ., New Brunswick, N.J. Lines: 11 I certainly agree that 802.3 is useless, and we should have stuck with DEC-Intel-Xerox Ethernet. However what seems to be happening in practice is that older protocols are ignoring 802.3, and newer ones are using it. Thus no incompatibility actually happens. That is, TCP/IP, PUP, and DECnet phase IV are using the Ethernet standards, while ISO and DECnet phase V will presumably use 802.3. For token rings, etc., that have no existing base of TCP/IP implementations, it appears that only an 802.3 encapsulation will be used. So we should not have compatibility problems in practice. That assumes no vendors get overly eager in their standard-following and try to do an 802.3 encapsulation for Ethernet. HP did that, and lost obviously enough that I think other vendors will be discouraged from following suit. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [18969@watmath.waterloo.edu] <1988051823574000> From: gamiddleton@watmath.waterloo.edu (Guy Middleton) Newsgroups: comp.protocols.tcp-ip Subject: subnetting supported by Sequents? Message-ID: <18969@watmath.waterloo.edu> Date: 18 May 88 23:57:40 GMT Reply-To: gamiddleton@watmath.waterloo.edu (Guy Middleton) Organization: University of Waterloo [MFCF/ICR] Lines: 2 Does anybody know whether the Sequent's version of Unix (called "Dynix", I think), supports subnetting yet? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805190058.AA09533@FORD-COS1.ARPA] <1988051900585100> From: jjkkrr@FORD-COS1.ARPA (J. Kevin Rohan) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8805190058.AA09533@FORD-COS1.ARPA> Date: 19 May 88 00:58:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 I'm looking for, if it exists as a standard, a document that describes the algorithm for mapping an IP class B or class C address into an X.25 address. I've got RFC 796 (that to the best of my knowledge has never been updated) and it doesn't cover X.25. I also have the NETINFO:X25.DOC and it covers the DDN's class A IP address, but I can't seem to find anything anywhere on the mapping of class B or C. It seems like gateways everywhere support this but where's the algorithm??? Thanks in advance!! Kevin Rohan jjkkrr@ford-cos1.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805190239.AA10180@acetes.dec.com] <1988051902393500> From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Message-ID: <8805190239.AA10180@acetes.dec.com> Date: 19 May 88 02:39:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 When I saw the first message asking about how to deal with Pups on 802.3 networks (the old Ethernet type code for Pup is a legal 802.3 length code), I thought to myself "nobody runs Pup on 10mb nets any more" (I wrote the code in the Stanford Unix Pup package to handle the 10mb stuff, and since this is apparently the only Pup code for Unix systems, I thought I knew something.) Then Darrel VanBuer writes that there's a new, "legal" code for Pup and Pup ARP. Does this mean that people still use Pup (outside of Xerox?) Wow! (Dave Boggs is going to love this one.) Does anyone really care if Pup coexists with 802.3 systems? If so, I'm doubly surprised. Does anyone want the same host to speak Pup and 802.3 ('cause otherwise the Pup hosts should drop the 802.3 packets due to bad checksums, and vice versa)? Sorry this is on TCP-IP, but I've noticed a tendency towards protocol archeology this week, and Pup certainly is a relic. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051906362800> Received: from umix.cc.umich.edu by SRI-NIC.ARPA with TCP; Thu, 19 May 88 15:49:33 PDT Received: by umix.cc.umich.edu (5.54/umix-2.0) id AA00338; Thu, 19 May 88 12:31:19 EDT Date: Thu, 19 May 88 10:36:28 EDT From: Doug_Nelson@um.cc.umich.edu To: kwe@bu-cs.bu.edu, tcp-ip@sri-nic.arpa Message-Id: <3064417@um.cc.umich.edu> Subject: Re: Subnetting [struct Enet addr] In response to Kent England's question: > It seems so obvious to me that a hierarchically structured > address space in Ethernet (read 802.x) 48 bit addresses would be a > great improvement over the current kludged 48 bit flat vendor-assigned > address space coupled with the 32 bit IP address space that I wonder > why the issue never comes up. I know all the obvious problems with > structured Ethernet addresses, but everytime I look at the issue it > seems to me that structured Ethernet/IP (read 802.x) addresses would > be a great improvement over flat address space. > > I think the 802 spec allows structured addressing, yes? Why > is there no hint of movement in this direction? Waiting for ISO? Or > have I failed to grasp some essential difficulty with this? Comments, > please. The most obvious difficulty with it is that it only fits the needs of IP. Many systems handle multiple protocols; they would be forced to constantly change their Ethernet address. And for what? To save 4 bytes on a high-speed medium, where packets are often padded because they're too short? And what do you do on other media where you have zero to two bytes of addressing? Note that DEC *is* using structured addresses for Ethernet. Note also that DEC is moving *away* from this in the future, since ISO addresses are too big to fit in Ethernet addresses. And that's where we're heading as well! Doug Nelson Michigan State University Computer Lab ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988051908335300> Received: from sonora.dec.com by SRI-NIC.ARPA with TCP; Thu, 19 May 88 15:53:38 PDT Received: from saturn.dec.com by sonora.dec.com (5.54.4/4.7.34) id AA21660; Thu, 19 May 88 15:31:51 PDT Received: by saturn.dec.com (5.54.3/4.7.34) id AA04147; Thu, 19 May 88 15:33:53 PDT Date: Thu, 19 May 88 15:33:53 PDT From: mogul@decwrl.dec.com (Jeffrey Mogul) Message-Id: <8805192233.AA04147@saturn.dec.com> To: tcp-ip@sri-nic.arpa Subject: Subnetting clarified It figures that a heated discussion of subnets would start about 3 hours after I left the country for 10 days. Anyway, at the risk of repeating some things that some of the wiser participants have already stated, I'd like to clarify a few points. I feel moderately justified in doing so; since I wrote the standard. First, I'd recommend that, before spouting off, everyone read RFC950 - Internet Standard Subnetting Procedure and RFC917 - Internet Subnets RFC950 is the Standard; RFC917 contains more explanatory information. Now, I am talking about an "Internet Standard", not "the answer to everyone's problems." This means that some people may find that a different approach would be a better solution to their specific problems. That is fine, but the subnetting standard was written to be a good solution for most people's problems. Not only that, we felt it vitally important that it be widely adopted; thus, it had to be easy to implement and it had to be a single solution. Nothing prevents the owner of an Internet network from running a different subnetting mechanism ... but if you use the standard mechanism, you can go to your vendor and complain if they aren't meeting the standard. One general complaint that people often raise is that it's hard to produce optimal routes under this standard. THAT IS PRECISELY THE POINT! To discover optimal routes, you need oodles of information. To keep the Internet managable (and to keep the routing tables from exploding), we need to keep the amount of routing information as small as possible. Optimal routing and a managable Internet are, to a certain extent, inherently adversarial goals (this is an oversimplification). Basically, if the routes you would get by using subnets are too awful, then you should consider getting more than one network number. The whole point of subnetting, then, is to hide local information from the global community; put another way, it is to impose a hierarchy on the routing information (and address management) so as to limit the remote impact of local complexity. The subnet structure of a network must be (is intended to be) completely invisible outside that network. Thus, it makes absolutely no sense to ask about how to route directly to the right subnet of somebody else's network, or to broadcast to a single subnet of a remote network, etc. Now, on to the mechanism: Before the Standard (RFC950) was issued, an intense discussion went on about how best to design it. One group argued for "self-describing" addresses; i.e., you could look at an address and (without any other information) determine how bits were allocated to subnet and host fields. To make a long story short, this method lost. Instead, the remarkably simple concept of an Address Mask is used. With each network is associated an Address Mask that is used to determine which bits select a specific host, and which select a specific data-link network. While it is in theory possible to associate different Address Masks with different subnets of a network (in conjuction with a self-encoding scheme such as the one used to separate Internet Address Classes), this is not what we intended when we wrote the Standard. (I'm not sure we managed to explicitly prohibit it.) It is certainly possible for a single host to be connected to two different networks (i.e., top-level networks) each with a different Address Mask, and so in the host software the Mask should be stored per-interface (as it is in 4.3BSD). In such an implementation, it might be possible to use different masks for different subnets of a single network, but I would not recommend this, since you might find that other implementations cannot handle this; the Standard does not explicitly require that they do so. Moreover, as it has been pointed out, there are subtle problems with this, since in order for a host to choose the right netmask for an outgoing packet, it has to know the self-encoding scheme as well. If you really need a single "big" subnet and a lot of little ones, consider getting two network numbers. I find it unlikely, however, that a single subnet with more than a few hundred hosts on it is going to be easily managable. Host software that does not allow the Address Mask to select an arbitrary division of bits between host field and subnet field (e.g., software that requires these fields to be a multiple of 8 bits wide) is not in compliance with the Standard. Proxy ARP is (in my opinion) not a good solution to the routing problem in general. Rather, it is a way for smart gateways to help dumb hosts; a "dumb host" is one whose software cannot handle subnetting. If you're stuck with such a host, your first step should be to complain to the software vendor, but Proxy ARP will carry you until the vendor makes good. One obvious problem with Proxy ARP is that it doesn't make any allowance for gateway crashes. One of the intended effects of the Address Mask mechanism is to insulate hosts, as much as possible, from the details of routing. I applaud the efforts to try to separate the "what are my neighbor gateways" question from the "what is the network topology" question. Passively listening to RIP broadcasts to learn a subset of local gateways might be a good idea, but peering inside those RIPs seems like a bad idea. I also like the idea of a multicast request that a host can use to discover its neighbor gateways; there are trivial solutions to the collision problem. (ARP does not seem to be the right mechanism for this, because it doesn't distinguish between "responder is THE target" and "responder is A first hop to the target".) Of course, on a non-broadcast medium, other gateway-acquisition mechanisms are necessary. I'll close by rephrasing a point I made earlier: the Subnetting Standard is not meant to be the perfect solution to everyone's problems. It is a pretty good solution to most people's problems, and it is a standard so you can hold vendors to it. Trying to take perverse advantage of ambiguities in the standard is like taking advantage of an undocumented effect of an instruction code; you will regret it later on. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [871@wright.EDU] <1988051911121700> From: jsloan@wright.EDU (John Sloan) Newsgroups: comp.protocols.tcp-ip,comp.sys.dec Subject: Re: Plenum-Rated Ethernet Transceivers Message-ID: <871@wright.EDU> Date: 19 May 88 11:12:17 GMT References: <410190444@nwnexus.WA.COM> Organization: Wright State University, Dayton OH, 45435 Lines: 27 in article <410190444@nwnexus.WA.COM>, edm@nwnexus.WA.COM (Ed Morin) says: > It turns out that the transceivers can be put into "air handling *spaces*" > (like ceilings), but *not* in actual ducting (i.e. main air supplies, etc.). I'm not sure there's much of a distinction in modern buildings. Many (including ours) use ductwork to deliver air to offices, then use the plenum (the air space above the ceiling) as an air return. Since the fire code is concerned about smoke and noxious fumes from burning materials (particularly plastic), which are the major causes of deaths in fires, spreading to other parts of the building (also making locating the fire very difficult), it would seem to me to be six of one, half dozen of the other. It sounds more to me like Cabletron was trying, not very successfully, to come up with a plausible explanation. Second worry of the day: I recently realized that some of the telephone closets are open to the plenum in the top... i.e. no ceiling. So, like, is that a plenum space or what? Third worry of the day: trying to explain to our new department chair why this is all so complicated ("why can't you just run a cable?" "because I don't want my a** sued off."). -- John Sloan, The SPOTS Group Wright State University Research Building CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!wright!jsloan +1-513-259-1384 +1-513-873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805191700.AA02087@bottom.ultra.com] <1988051917005800> From: ted@ultra.UUCP (Ted Schroeder) Newsgroups: comp.protocols.tcp-ip Subject: Re: Sources V.3.3 / 68020 TCP Stuff Message-ID: <8805191700.AA02087@bottom.ultra.com> Date: 19 May 88 17:00:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Please add me to the list of people also looking around for sources for TELNET, FTP, etc., etc., etc. Ted Schroeder ultra!ted@Ames.arc.nasa.GOV Ultra Network Technologies 2140 Bering drive with a domain server: San Jose, CA 95131 ted@Ultra.COM 408-922-0100 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12399598897.40.LYNCH@A.ISI.EDU] <1988051917110300> From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Third TCP-IP Book? Message-ID: <12399598897.40.LYNCH@A.ISI.EDU> Date: 19 May 88 17:11:03 GMT References: <8805170601.AA21125@Larry.McRCIM.McGill.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Philip, Unfortunately splitting the book in half does not mean dropping the price accordingly... Probably would only be able to drop the two halves to the high 20s. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1721@pt.cs.cmu.edu] <1988051917464000> From: ecc@spice.cs.cmu.edu (Eric Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Remote boot/debug protocols? Keywords: bootstrapping, debugging, protocols Message-ID: <1721@pt.cs.cmu.edu> Date: 19 May 88 17:46:40 GMT Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 7 Are there any protocols that support both bootstrapping and tele-debugging, with the machine-dependent parts nicely modularized? For the debugging functionality, I'm looking for something that could be put between the front and back ends of dbx or gdb. Any leads appreciated. Eric Cooper (ecc@cs.cmu.edu) Computer Science Department Carnegie Mellon University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21681@amdcad.AMD.COM] <1988051918475300> From: phil@amdcad.AMD.COM (Phil Ngai) Newsgroups: comp.sys.ibm.pc,comp.protocols.tcp-ip Subject: Re: Need info on Ethernet products for the IBM AT and Sun Message-ID: <21681@amdcad.AMD.COM> Date: 19 May 88 18:47:53 GMT References: <5503@potomac.ads.com> Reply-To: phil@amdcad.UUCP (Phil Ngai) Organization: Advanced Micro Devices Lines: 60 In article <5503@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes: >We would like to network our IBM AT to one of our Sun Microsystems >computers. The ideal method is to just plug the AT into the Sun's >ethernet network using an add--on ethernet interface card. Someone >recommended the Western Digital Ethercard for this purpose. This is a nice cheap high performance hardware configuration. But... >But what kind of software is available for the IBM AT that will let me >communicate with Suns? We would like to do basic things like file >transfer, finger, telnet and maybe hardcopy on the Sun from the AT if >that can be done. I have been (am using right now!) Sun's PC-NFS. I have personally done file transfer via FTP and telnet. It is supposed to do remote printing and NFS, I have not tried them. I was at first very pleased with the product, the telnet worked much better for me than Phil Karn's ka9q because I assume I did not have a good termcap for the PC's ansi.sys. PC-NFS emulates a vt-100 to a large degree. At present I do not believe PC-NFS works with the WD interface. I am using it with a (brain-damaged) 3Com interface. However, with use, cracks and problems show up in PC-NFS. Some are real problems, some might be called a nit but anyway, the product could be improved. 1) No support for multiple telnet sessions like ka9q. 2) No ftp server like ka9q. 3) ftp client blows up on mget with a small number of files, says "Arguments too long". 4) ftp client dies if you go back to telnet too long. 5) Host can't set tabs like a real VT-220 does (and I assume a VT-100 does). 6) No rlogin. 7) No .netrc for ftp means you always have to explicitly login. I've been waiting four days for an answer from Sun user support on 3). I expect they'll tell me "don't transfer so many files". >Would TOPS for the AT provide anything that I need? TOPS would have >to be run on the Sun I suppose and that's probably expensive. Are >there hardware interfaces for the AT that will let me communicate with >Appletalk (well there must be since people do connect ATs to >Appletalk)? Believe it or not, TOPS Corp (a division of Sun) makes a hardware interface for the AT that lets you talk Appletalk. But then if you want to talk to the Sun you'd need a Kinetics box and either Appletalk on the Sun or something like NCSA on the AT. I don't know that TOPS/Appletalk would do anything for an AT. The cost might be lower, but with the WD interface that's not clear. The performance is certainly not going to be nearly as good. -- Make Japan the 51st state! I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880519-134446-6569@Xerox] <1988051920401100> From: castillo.osbunorth@XEROX.COM Newsgroups: comp.protocols.tcp-ip Subject: Proteon's behaviour Message-ID: <880519-134446-6569@Xerox> Date: 19 May 88 20:40:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Burrell.osbunorth@Xerox.COM, castillo.osbunorth@Xerox.COM Organization: The Internet Lines: 19 I installed a Proteon router running standard TCP/IP software to connect our back bone net in our building with a private net in the same building (no external gateway, simply a router connecting 2 disjoint subnets). We have noticed some behaviour which seems to be a normal operation on the gateway, but that it is very annoying. It seems that the Proteon does some self testing of both of its Ethernet interfaces and other internal hardware by sending small trash packets to itself every so often through both interfaces. The frequency of such tests is often enough that it is noticibly consuming precious bandwidth already at a premium in our backbone which is carrying a lot of XNS traffic. Has anyone experienced such behaviour? Is there a way to reduce the frequency of the tests? ** julio ----MESSAGE-END---- ----MESSAGE-BEGIN---- [349@manta.NOSC.MIL] <1988051921232100> From: gutman@manta.NOSC.MIL (Lewis M. Gutman) Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso Subject: Transport Level Interface Keywords: Transport Level Interface, TLI Message-ID: <349@manta.NOSC.MIL> Date: 19 May 88 21:23:21 GMT Organization: Naval Ocean Systems Center, San Diego Lines: 11 A month or two ago I read something about the Transport Level Interface, being developed, I believe, at Bell Labs. My understanding was that it offered a standard interface to tcp. Can anyone shed any light on TLI? Can anyone suggest a reference? If TLI is not a software interface to tcp, can anyone tell me whether there is such a thing? Reply directly, please. Thanks in advance. Lew Gutman ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3616@psuvax1.psu.edu] <1988051922172100> From: ehrlich@blitz (Dan Ehrlich) Newsgroups: comp.protocols.tcp-ip Subject: Re: Competition for Bridge Message-ID: <3616@psuvax1.psu.edu> Date: 19 May 88 22:17:21 GMT References: <8805171310.AA03117@tut.cis.ohio-state.edu> Sender: news@psuvax1.psu.edu Reply-To: ehrlich@blitz (Dan Ehrlich) Organization: Department of Computer Science, Penn State University Lines: 16 In article <8805171310.AA03117@tut.cis.ohio-state.edu> tom@TUT.CIS.OHIO-STATE.EDU (Tom Easterday) writes: > > Dan, > > Could you give me a name and number for someone at Encore and CISCO to I have a number for Encore, but will have to track down CISCO. Our sales rep for Encore is Aaron Silberstrom, +1 301 762 8711. Encore just announced a 32 port version of there server with a faster CPU, more memory, etc. Cost: $8,500. --Dan Dan Ehrlich The Pennsylvania State University, Department of Computer Science 333 Whitmore Laboratory, University Park, PA 16802 +1 814 863 1142 or +1 814 865 9723 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1097@ditmela.oz] <1988052000555400> From: smart@ditmela.oz (Robert Smart) Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso Subject: OSI CLNS and the future of networking Message-ID: <1097@ditmela.oz> Date: 20 May 88 00:55:54 GMT Reply-To: smart@ditmela.oz.au (Robert Smart) Followup-To: comp.protocols.iso Organization: C.S.I.R.O. Division of Information Technology, Melbourne. Lines: 54 Helpppp! I am trying to understand where networking is going. I suspect I'm not the only one. As an investigative measure I present a guess based largely on rumour. Will the people who know please comment. The OSI CLNS (ConnectionLess Network Service) is basically just DoD's IP with minor changes (like a bigger address field). The objective is obviously to replace IP with CLNS. Presumably a subset of CLNS addresses is reserved for (and in simple arithmetic relation to) IP addresses. This will allow a mix of CLNS and IP as long as the backbone is CLNS. We can imagine that during the cutover there will be arrangements like this: IP CLNS IP IP1----IP/CLNS-gateway------IP/CLNS-gateway----IP2 Where IP1 and IP2 are ethernets still using IP. They shouldn't see any change talking to each other. The question then is how they will talk to people who have made the cutover. Presumably the gateways will have to have tables (presumably built dynamically by querying relevant servers) of CLNS to IP addresses: CLNS hosts which wish to be able to talk to IP hosts will have to have their IP-equivalent address registered so the gateway has a replacement IP address to use for that CLNS address when packets enter the IP world (and contrari-wise). Those gateways will need fast processors in them. If CLNS hosts are going to talk to IP hosts (and this is absolutely essential if the whole thing is going to get off the ground) then obviously the first middle level protocols to be implemented will be TCP/CLNS and UDP/CLNS, and the associated application level protocols. This should be a trivial modification of existing TCP/IP and UDP/IP code. The nice thing about going to CLNS is that you can then start running other high level protocols. In particular CLNS/TP4 will give access to the OSI higher level protocols [I know the X.400 standard says that it must run only over TP0 and only over X.25 but this is just a pathetic attempt by the PTTs to force people to use X.25. No sensible implementations will enforce this restriction. DECs implementation (MRX) currently allows TP4 over ethernet]. The next interesting thing is that DEC says DECNET Phase V will work over CLNS. So presumably VAXes (and other computers) on the CLNS Internet will be able to talk DECNET to each other. That's all very well, but I would like to understand how CLNS over X.25 coexists with the existing CONS (ConnectionOriented Network Service) over X.25. I guess they just use different Subaddress or Protocol-id or Call User Data. I am also not sure how CLNS over 802.3 fits in with existing OSI over 802.3. Presumably the packets will have CLNS sender and destination addresses in them (the new IP addresses). That certainly isn't what is in them now. Bob Smart, CSIRO Division of Information Technology, Australia ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052001512900> Received: from CORNELLC.CCS.CORNELL.EDU by SRI-NIC.ARPA with TCP; Sat, 21 May 88 08:50:45 PDT Received: from MSSTATE.BITNET by CORNELLC.CCS.CORNELL.EDU ; Sat, 21 May 88 11:50:02 EDT Date: Fri, 20 May 88 06:51:29 CDT From: Mike Rackley Subject: TCP/IP platform. To: We are in the early stages of implementing a campus fiber optic backbone that will link a variety of equipment together using TCP/IP as the protocol of choice. We are also connecting to one of the NSF regional nets, SURANET, sometime this summer. As is the case with most university environments, we have a rather chaotic mix of hardware and software that we are trying to bring together. We are also fairly new at the TCP/IP game and have many more questions than answers. In general, I am looking for a UNIX box such as a MicroVAX, IBM RT or SUN workstation to fulfill several requirements. I want a stable, up-to-date TCP/IP implementation that I can use as a benchmark when diagnosing problems. That is, I want the TCP/IP on this box to be a known commodity that I can depend upon to perform as it should. Next, I want to have available a large suite of software "goodies" that I can use in conjunction with the network to gain experience with the capabilities of TCP/IP. Things in this category might include a file server capability like NFS, and network monitoring/diagnostic software. Next, I want this box to be able to provide some routine, network-wide services such as domain name server and time server. And finally, I want this to be a box from a vendor that is likely to stay on the leading edge of TCP/IP and OSI developments. I would appreciate any suggestions as to vendor, hardware and software that might satisfy my requirements. Although I would hope to spend less that $20,000 for such a system, please do not let cost affect your recommendations. Thanks, Mike Rackley Mississippi State U. Computer Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22208@tis.llnl.gov] <1988052002063500> From: bae@ati.tis.llnl.gov (Hwa Jin Bae) Newsgroups: comp.protocols.tcp-ip Subject: Re: SendMail Message-ID: <22208@tis.llnl.gov> Date: 20 May 88 02:06:35 GMT References: <8805180903.aa03398@CAD.USNA.MIL> Sender: news@tis.llnl.gov Reply-To: bae@ati.tis.llnl.gov (Hwa Jin Bae) Organization: Lawrence Livermore National Laboratory, Livermore CA Lines: 25 In article <8805180903.aa03398@CAD.USNA.MIL> tsmith@USNA.MIL ("Tim G. Smith", Mechanical) writes: >We currently use MMDF as our mail handler but are in the process of >switching to sendmail as sendmail seems to be emerging as the >"standard" mail handler. No offense. But in my view MMDF has far better design than sendmail. I don't see why you would go from MMDF to sendmail. The other way around makes much more sense. I guess I've actually lived long enough to hear someone say "I LIKE SENDMAIL!". sendmail is a very sickening piece of software - overblown, unnecessarily complicated, huge Mo.Fo. I don't know how you are using MMDF but it's concept is closer to modern mail system models like X.400 where several delivery mechanism can be handled transparently. MMDF allows you to have separate processes for mail delivery channels which can be totally different. One of the channels may be sendmail since it does implement SMTP. I would prefer to use simpler SMTP mailer though. It's truely incredible to see how a Simple Mail Tranfer Protocol can be implemented in such Complex ways (as in sendmail), which tries to do too much. I think I've work on sendmail code enough to know that it is the ultimate example of the BSD mentality - 10 times more flexible but 100 bigger and more complex. ----- Hwa Jin Bae | The Devil made me do it...yeah, that's right! Control Data Corp. | (415) 463 - 6865 4234 Hacienda Drive | bae@tis.llnl.gov (Internet) Pleasanton, CA 94566 | {ames,ihnp4,lll-crg}!lll-tis!bae (UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [May.19.22.13.22.1988.5199@athos.rutgers.edu] <1988052002133100> From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: Date: 20 May 88 02:13:31 GMT References: <8805161548.AA15786@oliver.cray.com> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 10 Proxy ARP can be used for all routing, not just subnet routing. The idea is to give your hosts default routes that tell them to treat everything as on the local cable. This is done in Unix by doing route add 0.0.0.0 YOURADDRESS 0 where YOURADDRESS is the Internet address associated with your Ethernet interface (if you have more than one, the one you want used as default). By using a metric of 0, you tell the system to treat this route as on the local cable, so it issues ARP's rather than using a gateway. It is of course possible that some TCP/IP implementations don't have an equivalent kludge, but many of them seem to. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4733@super.upenn.edu] <1988052005141800> From: hagan@scotty.dccs.upenn.edu (John Dotts Hagan) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong's TCP/IP Message-ID: <4733@super.upenn.edu> Date: 20 May 88 05:14:18 GMT References: <8805061531.AA22148@ucbvax.Berkeley.EDU> Sender: news@super.upenn.edu Reply-To: hagan@scotty.dccs.upenn.edu (John Dotts Hagan) Organization: University of Pennsylvania Lines: 8 The University of Pennsylvania Data Communications and Computing Services group has chosen WIN/TCP for VMS as the best solution for VMS TCP/IP. We are not using any of them as Domain Name Servers, but they all work very well as DNS clients. In fact, the system works better than standard 4.2bsd (many 4.2 TCP/IP problems are fixed). --Kid. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [508@sering.cwi.nl] <1988052011274100> From: piet@cwi.nl (Piet Beertema) Newsgroups: comp.protocols.tcp-ip Subject: Re: SendMail Message-ID: <508@sering.cwi.nl> Date: 20 May 88 11:27:41 GMT References: <8805180903.aa03398@CAD.USNA.MIL> <22208@tis.llnl.gov> Organization: CWI, Amsterdam Lines: 13 >No offense. But in my view MMDF has far better design than sendmail. >I don't see why you would go from MMDF to sendmail. The other way around >makes much more sense. I guess I've actually lived long enough to >hear someone say "I LIKE SENDMAIL!". sendmail is a very sickening >piece of software - overblown, unnecessarily complicated, I like sendmail too, for various reasons. But this is not exactly a newsgroup to fight out a largely theological discussion. -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805221538.AA00232@ucbvax.Berkeley.EDU] <1988052011512900> From: RACKLEY@MSSTATE.BITNET (Mike Rackley) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP platform. Message-ID: <8805221538.AA00232@ucbvax.Berkeley.EDU> Date: 20 May 88 11:51:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 31 We are in the early stages of implementing a campus fiber optic backbone that will link a variety of equipment together using TCP/IP as the protocol of choice. We are also connecting to one of the NSF regional nets, SURANET, sometime this summer. As is the case with most university environments, we have a rather chaotic mix of hardware and software that we are trying to bring together. We are also fairly new at the TCP/IP game and have many more questions than answers. In general, I am looking for a UNIX box such as a MicroVAX, IBM RT or SUN workstation to fulfill several requirements. I want a stable, up-to-date TCP/IP implementation that I can use as a benchmark when diagnosing problems. That is, I want the TCP/IP on this box to be a known commodity that I can depend upon to perform as it should. Next, I want to have available a large suite of software "goodies" that I can use in conjunction with the network to gain experience with the capabilities of TCP/IP. Things in this category might include a file server capability like NFS, and network monitoring/diagnostic software. Next, I want this box to be able to provide some routine, network-wide services such as domain name server and time server. And finally, I want this to be a box from a vendor that is likely to stay on the leading edge of TCP/IP and OSI developments. I would appreciate any suggestions as to vendor, hardware and software that might satisfy my requirements. Although I would hope to spend less that $20,000 for such a system, please do not let cost affect your recommendations. Thanks, Mike Rackley Mississippi State U. Computer Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052012133000> Received: from GOVERNMENT-CENTER.BBN.COM by SRI-NIC.ARPA with TCP; Fri, 20 May 88 13:57:18 PDT Date: Fri, 20 May 88 16:13:30 EDT From: Ross Callon To: dpowles@CCD.BBN.COM cc: tcp-ip@SRI-NIC.ARPA, rcallon@bbn.com Subject: Re: connecting Internets? Drew; I think the answer is a qualified yes. There are several "sub-issues" however. In a sense the issues involved in interconnecting multiple existing "Internets" are the same as those in having the Internet grow to encompass a large number of administrative domains, except for the added problem of address overlap (which is probably NOT the worst problem). In terms of address overlap, the solution depends upon whether you use the DoD IP or the ISO IP. With the DoD IP, I am not aware of any work on how to map between two overlapping inconsistent address sets. The obvious choice would be to more or less hand-configure some sort of translation, and have big tables in the gateways on the boundary. Exactly how this is done may depend on whether you run out of network numbers for any particular class of network address. For example, if a class A address on one side maps to a class B address on the other, then the host part of the address would also have to change. All of this seems potentially ugly. The ISO protocol, on the other hand, comes complete with globally unique addresses. For example, consider the proposed ways in which addressing could be done with the ISO IP in the DoD Internet (see RFC986, IDEA003, and a revision of both which is about to come out as a new RFC). Here the first three octets of the address specify "DoD Internet", and addresses are globally unique even with respect to Internets in some other part of the world. Another potentially more serious question regards how to route in a future world of multiple "Internets" (or a multi-domain Internet). It can be assumed that most of the administrative domains in the world will have strict restrictions on what sort of traffic they are willing to carry for what users. For example, a particular domain may be willing to carry any traffic which is strictly internal, traffic between this domain and neighbors only for specific users and/or applications, and transit traffic only for a small number of outside domains and specified applications. The domain may be very willing to carry electronic mail traffic for their main competitor, because they want to make copies for themselves (the main competitor may, for the same reason, be unwilling to use this service). One can easily envision all sorts of other "policy constraints" affecting routing. Thus routing will need to look at all sorts of administrative and policy considerations. The IETF Open Routing working group is currently thinking about how one may do this. IDEA003 represents a first draft of the requirements for inter-AS (or Inter-domain) routing, but is only in draft form (there is a list of proposed updates to be made in the future). We are currently working on several proposals for how to actually do routing in this environment. The Autonomous Networks Task Force is also working on related issues. There are other issues that are likely to come up when multiple "Internets" are interconnected. For example, there may be a need for congestion control to be sensitive to administrative policies and contractural arrangements. Ross ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1725@pt.cs.cmu.edu] <1988052012391100> From: ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) Newsgroups: comp.protocols.tcp-ip Subject: Re: Proxy ARP (was Re: Dumb vs. smart host routing) Message-ID: <1725@pt.cs.cmu.edu> Date: 20 May 88 12:39:11 GMT References: <864@kaos.UUCP> <12398059730.20.BILLW@MATHOM.CISCO.COM> <882@kaos.UUCP> Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 19 In article <882@kaos.UUCP> romkey@kaos.UUCP (John Romkey) writes: > >Bill, > >I hate to do this, but I don't like proxy ARP at all. ... >First, there are too many network media that don't use ARP for my >taste. ARPANET, X.25, ProNET-10. Maybe FDDI won't? I suppose I should give Phil Karn a chance to say this first, but AMPRnet (Amateur Packet Radio, network 44) generally won't - hidden terminal problems and unreliable broadcast performance make it impractical. Unfortunately, ARP has become too popular, so that people almost always think of trying to use it to help with routing. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052012544500> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Sat, 21 May 88 20:26:54 PDT Received: from PYTHAG.UCL.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 7445; Fri, 20 May 88 03:40:57 EDT Received: by BUCLLN11 (Mailer X1.25) id 8645; Fri, 20 May 88 09:38:46 +02 Date: Fri, 20 May 88 09:34:45 +0200 From: "Alain FONTAINE (Postmaster - NAD)" Subject: RFC821/RFC822 route syntax. To: TCP-IP@SRI-NIC.ARPA Could somebody tell me if I do read correctly a correct version of RFC821 and RFC822 ? From what see the syntax for the route part of a route-address is : in RFC821 : @domain1,@domain2,@domain3: in RFC822 : @domain1@domain2@domain3: Maybe this is clear for everybody except me... Thanks. /AF ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052015004600> Received: from clash.cisco.com by SRI-NIC.ARPA with TCP; Fri, 20 May 88 22:06:10 PDT Received: from clash.cisco.com by clash.cisco.com with TCP; Fri, 20 May 88 22:00:48 PDT To: jjkkrr@ford-cos1.arpa (J. Kevin Rohan) Cc: tcp-ip@sri-nic.arpa In-Reply-To: Your message of Wed, 18 May 88 18:58:51 -0600. <8805190058.AA09533@FORD-COS1.ARPA> Date: Fri, 20 May 88 22:00:46 PDT From: satz@clash.cisco.com Kevin, Someone was supposed to write up an RFC describing the mapping used for class B and C addresses. What is currently being used in the cisco DDN X.25 implementation is: class A: N.H.L.I class B: N.N.H.I class C: N.N.N.HI Where N represents the network number. H represents the PSN port number. L is the logical host field and is still zero. I is the PSN number. For class B addresses, the H field uses the unused L field. For class C addresses, the H field lies in the upper four bits of the last octet and the I field in the lower four. I don't know of anyone who has a class C PSN network. Hope this helps, Greg Satz cisco ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805201500.AA27355@csc-lons.ARPA] <1988052015005900> From: scottr@CSC-LONS.ARPA (Scott W. Rogers) Newsgroups: comp.protocols.tcp-ip Subject: LOOPBACK Net Number Message-ID: <8805201500.AA27355@csc-lons.ARPA> Date: 20 May 88 15:00:59 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: Computer Sciences Corporation. Lines: 15 Qeustion to all you network GURU's: 05/20/88 Is there a standard for a loopback address. On BSD machines I've seen it is usually 127.0.0.1, however EXCELNA defaults to 127.0.0.0. Both let you override the default. I did not see any references to loopback addresses in the RFC index. Any comments or suggestions on where to look? Thanks, ------------------------------------------------------------------------ Scott W. Rogers Computer Sciences Corporation - Systems Division AT&T: (703) 876-1363 3160 Fairview Park Dr. - Falls Church, VA 22152 Fax: (703) 876-4072 Internet: scottr@csc-lons.ARPA ------------------------------------------------------------------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805201641.AA11833@mtxinu.UUCP] <1988052015544900> From: minshall@kinetics.UUCP (Greg Minshall) Newsgroups: comp.protocols.tcp-ip Subject: Re: hosts and gateways and protocols Message-ID: <8805201641.AA11833@mtxinu.UUCP> Date: 20 May 88 15:54:49 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 31 (I said I listen for RIP packets to find a gateway. Frank Kastenholz responded...) > This assumes that your host can understand that the packet is a RIP > packet. If my routers use another IGP then the hosts will not know that > it is an IGP packet so they can not "backtrack" to the source of the > packet and get a router. Yes, I understand that. That's why I would like one protocol which says "I am a router" that *everyone* uses. Today, however, there is no such protocol. As a practical matter I use RIP (and wouldn't mind using a few more). (I said...) > >I also feel for those souls whose routers occasionally crash, and who would > >like routes to switch automatically. I don't believe that just because > >you need this capability once per day that should exclude it from being > >automated. > Unfortunately I must strongly disagree with the last sentence. TCP/IP is > entering the non-technical world very rapidly. The company that I work >... > and more networks. the failure recovery mechanism MUST BE AUTOMATIC. The > recovery mechanism is required for a very simple reason - money. ... Sorry. I was in "poor English" mode. You and I are in total agreement. I worded my sentence poorly. Greg Minshall Kinetics, Inc. (415)947-0998 ...ucbvax!mtxinu!kinetics!minshall ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5534@aw.sei.cmu.edu] <1988052016054800> From: pdb@sei.cmu.edu (Patrick Barron) Newsgroups: comp.protocols.tcp-ip Subject: Re: SendMail Message-ID: <5534@aw.sei.cmu.edu> Date: 20 May 88 16:05:48 GMT References: <8805180903.aa03398@CAD.USNA.MIL> <22208@tis.llnl.gov> Sender: netnews@sei.cmu.edu Reply-To: pdb@sei.cmu.edu (Pat Barron) Followup-To: comp.mail.sendmail Organization: Carnegie-Mellon University, SEI, Pgh, Pa Lines: 20 In article <22208@tis.llnl.gov> bae@ati.tis.llnl.gov (Hwa Jin Bae) writes: >I don't know how you are using MMDF but it's >concept is closer to modern mail system models like X.400 where several >delivery mechanism can be handled transparently. MMDF allows you to >have separate processes for mail delivery channels which can be totally >different. sendmail will let you do exactly the same thing - it's not just a big, complicated SMTP implementation. It can do UUCP, BITNET, SMTP, local Unix mail, etc. It can let you vary how (or if, at all) a message gets delivered depending on what the address looks like and/or who the sender is. You can define different mailers which use the same delivery mechanism but with different parameters. I'll certainly admit that it's very complex, probably much more so than it needs to be - especially if you have to hack the configuration file. [Usenet followups redirected to comp.mail.sendmail] --Pat. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2417@zaphod.UUCP] <1988052016192400> From: bradg@zaphod.UUCP (The Rogue Warrior) Newsgroups: comp.protocols.tcp-ip Subject: Getting RFCs (was: RIP, gated reply summary) Summary: arpanet to uucp Message-ID: <2417@zaphod.UUCP> Date: 20 May 88 16:19:24 GMT References: <2875@emory.uucp> Reply-To: bradg@zaphod.UUCP (The Rogue Warrior) Organization: Develcon Electronics, Saskatoon SK Canada Lines: 7 In article <2875@emory.uucp> ospwd@emory.uucp (Peter Day {EUCC}) writes: >RFCs are available from a number of sources, but in particular, >may be obtained by sending a note to >service@sri-nic.arpa with Subject: RFC nnn ^^^^^^^^^^^^^^^^^^^^ Could someone please give me the corresponding UUCP address if one exists or, if not, a way to get from UUCP to the ARPAnet? Thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [525@xios.XIOS.UUCP] <1988052016454700> From: peter@xios.XIOS.UUCP (Peter Manson) Newsgroups: comp.protocols.tcp-ip Subject: PING with source/record route Message-ID: <525@xios.XIOS.UUCP> Date: 20 May 88 16:45:47 GMT Article-I.D.: xios.525 Posted: Fri May 20 12:45:47 1988 Organization: XIOS Systems Corporation, Ottawa, Ontario, Canada Lines: 26 A while ago there was an article here from someone who had modified PING to provide source and/or record route functions (and maybe some other things in addition to 4.3 PING). Unfortunately, I didn't save it. If anyone has information on this (or better still, the source or the modifications), please send me mail. General info about PING and other enhancements to it would also be appreciated. Thanks very much. ---------------------------------------------------------------------------- Peter Manson | XIOS Systems Corp. | 150-1600 Carling Avenue, | peter@xios.uucp from UUCP Ottawa, Ontario | xios.uucp!peter@uunet.uu.net from Internet K1Z 8R8 | CANADA | (613) 725-5411 | -- ---------------------------------------------------------------------------- Peter Manson | XIOS Systems Corp. | 150-1600 Carling Avenue, | peter@xios.uucp from UUCP Ottawa, Ontario | xios.uucp!peter@uunet.uu.net from Internet K1Z 8R8 | CANADA | (613) 725-5411 | ----MESSAGE-END---- ----MESSAGE-BEGIN---- [509.580153365@atom] <1988052017424500> From: norm@atom.hpl.hp.COM (Norman Kincl) Newsgroups: comp.protocols.tcp-ip Subject: Re: 802 (.2).3 TCP/IP Message-ID: <509.580153365@atom> Date: 20 May 88 17:42:45 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 27 > I certainly agree that 802.3 is useless, and we should have stuck with > DEC-Intel-Xerox Ethernet. However what seems to be happening in > practice is that older protocols are ignoring 802.3, and newer ones > are using it. Thus no incompatibility actually happens. That is, > TCP/IP, PUP, and DECnet phase IV are using the Ethernet standards, > while ISO and DECnet phase V will presumably use 802.3. For token > rings, etc., that have no existing base of TCP/IP implementations, it > appears that only an 802.3 encapsulation will be used. So we should > not have compatibility problems in practice. That assumes no vendors > get overly eager in their standard-following and try to do an 802.3 > encapsulation for Ethernet. HP did that, and lost obviously enough > that I think other vendors will be discouraged from following suit. Are you not confusing 802.3 with 802.2? 802.3 (physical layer) is essentially identical to Ethernet physical layer (the grounding pin is different and there is one other difference in there somewhere). It is not hard to make a card that can be fully compatible with both. Most cards these days don't really care if they are connected via an transceiver cable to a transceiver (Ethernet) or via an AUI cable to a MAU (802.3). 802.2 (data link layer) is where the problem comes in. Though you can have a system that speaks both quite fluently (eg. HP9000 or cisco box), most systems do not do that and provide only one of those data link layers (usually Ethernet). (There is no such thing as 802.3 token ring---that comes under 802.5) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [30098@ccicpg.UUCP] <1988052017480100> From: miket@ccicpg.UUCP (Mike Tracy) Newsgroups: comp.protocols.tcp-ip Subject: Re: 802 (.2).3 TCP/IP Message-ID: <30098@ccicpg.UUCP> Date: 20 May 88 17:48:01 GMT References: <14933@sgi.SGI.COM> Reply-To: miket@ccicpg.UUCP (Mike Tracy) Distribution: na Organization: CCI CPG, Irvine CA Lines: 26 in article <14933@sgi.SGI.COM>, vjs@rhyolite.SGI.COM (Vernon Schryver) says: > > In article <1080@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes: >> I see only one easy answer to the gratuitous compatibility problems >> imposed by 802.3: IGNORE IT! ... > > Yes, but...some vendors are already supporting it. I'm told by some of > our customers that Gould/SEL machines can do either 'Ethernet 1 or > 802.3' (meaning either lengths or types), depending on boot-time > configuration, and cannot send even raw ethernet packets of one kind > when configured for the other. Are you sure they don't mean ethenet 2 ? Many vendors claim to be 802.3 compatable but actually are only compatable up to the frame format. All of the electrical stuff, CSMA/CD, etc. is 802.3 but they use they standard ethernet frame format (i.e. type instead of length). Probably, if they are running Unix, they are ethernet 2. Otherwise, it makes it hard to talk to other Unix boxes. :-> -- Michael D. Tracy CCI Computers (714)458-7282 9801 Muirlands Boulevard Irvine, CA 92718 uunet!ccicpg!miket ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1483@nrcvax.UUCP] <1988052019483600> From: ihm@nrcvax.UUCP (Ian H. Merritt) Newsgroups: comp.protocols.tcp-ip Subject: Re: Toothpaste, but also *disinfectant*! Message-ID: <1483@nrcvax.UUCP> Date: 20 May 88 19:48:36 GMT References: <8805180210.AA08976@ucbvax.Berkeley.EDU> Reply-To: ihm@minnie.UUCP (Ian Merritt) Organization: The Frobboz Magic Dungeon Co., Inc. Lines: 9 CDBP01@VAXD.STRATHCLYDE.AC.UK says: >Competition time: how many uses for liquid TCP could be found for Real TCP? It seems that a liquid TCP could do wonders for the fragmentation problems commonly found on the network. Consider how easy reassembly would become (;->) -i ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805210151.AA09745@ucbvax.Berkeley.EDU] <1988052020133000> From: rcallon@GOVERNMENT-CENTER.BBN.COM (Ross Callon) Newsgroups: comp.protocols.tcp-ip Subject: Re: connecting Internets? Message-ID: <8805210151.AA09745@ucbvax.Berkeley.EDU> Date: 20 May 88 20:13:30 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 53 Drew; I think the answer is a qualified yes. There are several "sub-issues" however. In a sense the issues involved in interconnecting multiple existing "Internets" are the same as those in having the Internet grow to encompass a large number of administrative domains, except for the added problem of address overlap (which is probably NOT the worst problem). In terms of address overlap, the solution depends upon whether you use the DoD IP or the ISO IP. With the DoD IP, I am not aware of any work on how to map between two overlapping inconsistent address sets. The obvious choice would be to more or less hand-configure some sort of translation, and have big tables in the gateways on the boundary. Exactly how this is done may depend on whether you run out of network numbers for any particular class of network address. For example, if a class A address on one side maps to a class B address on the other, then the host part of the address would also have to change. All of this seems potentially ugly. The ISO protocol, on the other hand, comes complete with globally unique addresses. For example, consider the proposed ways in which addressing could be done with the ISO IP in the DoD Internet (see RFC986, IDEA003, and a revision of both which is about to come out as a new RFC). Here the first three octets of the address specify "DoD Internet", and addresses are globally unique even with respect to Internets in some other part of the world. Another potentially more serious question regards how to route in a future world of multiple "Internets" (or a multi-domain Internet). It can be assumed that most of the administrative domains in the world will have strict restrictions on what sort of traffic they are willing to carry for what users. For example, a particular domain may be willing to carry any traffic which is strictly internal, traffic between this domain and neighbors only for specific users and/or applications, and transit traffic only for a small number of outside domains and specified applications. The domain may be very willing to carry electronic mail traffic for their main competitor, because they want to make copies for themselves (the main competitor may, for the same reason, be unwilling to use this service). One can easily envision all sorts of other "policy constraints" affecting routing. Thus routing will need to look at all sorts of administrative and policy considerations. The IETF Open Routing working group is currently thinking about how one may do this. IDEA003 represents a first draft of the requirements for inter-AS (or Inter-domain) routing, but is only in draft form (there is a list of proposed updates to be made in the future). We are currently working on several proposals for how to actually do routing in this environment. The Autonomous Networks Task Force is also working on related issues. There are other issues that are likely to come up when multiple "Internets" are interconnected. For example, there may be a need for congestion control to be sensitive to administrative policies and contractural arrangements. Ross ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12399897330.45.MKL@SRI-NIC.ARPA] <1988052020302400> From: MKL@SRI-NIC.ARPA (Mark Lottor) Newsgroups: comp.protocols.tcp-ip Subject: Re: LOOPBACK Net Number Message-ID: <12399897330.45.MKL@SRI-NIC.ARPA> Date: 20 May 88 20:30:24 GMT References: <8805201500.AA27355@csc-lons.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 RFC 1009 defines the standard loopback address as {127,any} for the {net,host} pair. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22166@oliveb.olivetti.com] <1988052022212400> From: jerry@oliveb.olivetti.com (Jerry Aguirre) Newsgroups: comp.sys.ibm.pc,comp.protocols.tcp-ip Subject: Re: Need info on Ethernet products for the IBM AT and Sun Message-ID: <22166@oliveb.olivetti.com> Date: 20 May 88 22:21:24 GMT References: <5503@potomac.ads.com> <21681@amdcad.AMD.COM> Reply-To: jerry@oliveb.UUCP (Jerry Aguirre) Organization: Olivetti ATC; Cupertino, Ca Lines: 14 In article <21681@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes: >At present I do not believe PC-NFS works with the WD interface. I am >using it with a (brain-damaged) 3Com interface. I have version 3.0 of PC-NFS and it lists the following configuration options for the ethernet adapter: 3Com 3C501, 3C503, 3C505, 3C523 Ungermann-Bass NIC, NIU Western Digital WD8003E Micom-Interlan NI5010 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805202234.AA28682@coco3] <1988052022342500> From: garcia@TSCA.ISTC.SRI.COM Newsgroups: comp.protocols.tcp-ip Subject: Advance Program SIGCOMM 88 Symposium Message-ID: <8805202234.AA28682@coco3> Date: 20 May 88 22:34:25 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 422 All, Enclosed is the advance program and registration form for the 1988 ACM SIGCOMM symposium. SIGCOMM is THE ACM symposium on computer communications. This year we have a very strong technical program, consisting of three days of conference papers, plus one tutorial day. For more information about hotels and on-campus accommodations, please contact Stanford University directly (415/723-3126). Please note that VERY limited on-campus accommodations are available. To expedite the registration process, you can send print outs of the attached forms with payment. Sincerely, JJ Garcia-Luna General Chair, SIGCOMM 88 ----------------------------------------------------------------------- ACM SIGCOMM 88 SYMPOSIUM ADVANCE PROGRAM Communications Architectures and Protocols August 16-19, 1988 Stanford University, Stanford, California SYMPOSIUM August 17-19, 1988 August 17, 1988 9:00 - 10:00 Session 1: Keynote Session General Chair: J.J. Garcia-Luna-Aceves, SRI International, USA Program Chair: L. Landweber, University of Wisconsin, USA Student Paper Award: J.J. Garcia-Luna-Aceves, SRI International, USA Keynote Address: Donald Nielson, SRI International, USA 10:30 - 12:00 Session 2: Local/Metropolitan Area Internets Chair: D. Anderson, Unviversity of California, Berkeley, USA Topological Analysis of Local-Area Internetworks (G. Trewitt, Stanford University) --- Student Paper Dynamic Resource Allocation in a Metropolitan Area Network (K. Maly, C. Overstreet, Old Dominion Univ.; X. Qui, China State Shipbuilding Corporation, Peoples Republic of China; and D. Tang, Chengdu University of Science & Technology, Peoples Republic of China) Optical Interconnection Using ShuffleNet Multihop Networks in Multi-Connected Ring Topologies (M.J. Karol, AT&T Bell Laboratories, USA) 1:15 - 2:45 Session 3: Routing Chair: L. Chapin, Data General Corporation, USA Landmark Routing: Distributed Name-Based Routing for Very Large Networks (P.F. Tsuchiya, Mitre, USA) Pitfalls of a Certain Class of Distributed Routing Algorithms (R. Perlman and G. Varghese, DEC, USA) Multicast Routing in Internetworks and Extended LANs (S.E. Deering, Stanford University, USA) --- Student Paper 3:15 - 5:15 Session 4: Transport Level and Operating System Issues Chair: S. Lam, University of Texas at Austin, USA Design of an x-Kernel (N. Hutchinson and L. Peterson, Univ. of Arizona, USA) Exploiting Recursion to Simplify RPC Communication Architectures (D.R. Cheriton, Stanford University, USA) Service Specification and Protocol Construction for the Transport Layer (S.L. Murphy and A.U. Shankar, Univ. of Maryland at College Park, USA) A Network Management Language for OSI Networks (U. Warrier, A. Relan, Unisys Corporation, USA; O. Berry, IBM Science and Technology, Israel; and J. Bannister, The Aerospace Corporation, USA) 7:00 pm - on Banquet August 18, 1988 8:30 - 10:00 Session 5: Lessons of the Internet Chair: J. Mogul, Digital Equipment Corporation, USA Some thoughts on the DARPA Internet Architecture (David Clark, MIT, USA) The Fuzzball (D.L. Mills, University of Delaware, USA) Development of the Domain Name System (Paul Mockapetris, USC Information Sciences Institute, USA) 10:30 - 12:00 Session 6: Local Area Network Architecture Chair: R. Cheung, Hewlett-Packard, USA Optimizing Bulk Data Transfer Performance: The Packet Train Model (C. Song and L.H. Landweber, University of Wisconsin, USA) --- Student paper A Mesh/Token Ring Hybrid-Architecture LAN (C. Kang, The American University, USA; and J. Herzog, Oregon State University, USA) Tree LANs with Collision Avoidance: Protocol, Switch Architecture, and Simulated Performance (T. Suda, S. Morris, and T. Nguyen, University of California, Irvine, USA) 1:15 - 2:45 Session 7: Very High Speed Networking Chair: D. Farber, University of Pennsylvania, USA An Analysis of Memnet - An Experiment in High Speed Memory Mapped Local Networking (G. Delp, A. Sethi, University of Delaware, USA; and D. Farber, University of Pennsylvania, USA) --- Student paper The VMP Network Adapter Board (NAB): High-Performance Network Communication for Multiprocessors (H. Kanakia and D. Cheriton, Stanford University, USA) --- Student paper Fast Circuit Switching in Fiber Optic Networks (I. Chlamtac, A. Ganz, and G. Karmi, University of Massachusetts, USA) 3:15 - 5:15 Session 8. Measurement and Management Chair: V. Cerf, Corporation for National Research Initiatives, USA A Pseudo-Machine for Packet Monitoring and Statistics (R.T. Braden, USC Information Sciences Institute, USA) Knowledge-Based Monitoring and Control: An Approach to Understanding the Behavior of TCP/IP Network Protocols (B.L. Hitson, Stanford University, USA) --- Student paper Measured Capacity of an Ethernet (D.R. Boggs, J.C. Mogul, and C.A. Kent, DEC, USA) Distributed Testing and Measurement across the Atlantic Packet Satellite Network (SATNET) (K. Seo, BBN, USA; J. Crowcroft, UCL, England; P. Spilling, Norwegian Telecommunications Administration, Norway; J. Laws, Royal Signals and Radar Establishment, Englanand; and C. Topolcic, BBN, USA) 5:30 - 7:00 Reception August 19, 1988 8:30 - 10:00 Session 9: Communication Protocol Design and Testing Chair: D. Mills, University of Delaware, USA A Multicast Transport Protocol (J. Crowcroft and K. Paliwoda, University College London, England) Experience with Test Generation for Real Protocols (D. Sidhu and T. Leung, Iowa State University, USA) Performance Models for Noahnet (G.M. Parulkar, A.S. Sethi, D.J. Farber, University of Pennsylvania, USA) 10:30 - 12:00 Session 10: Broadcast Issues Chair: D. Sidhu, Iowa State University, USA A High Performance Broadcast File Transfer Protocol (J.S.J. Daka, A.G. Waters, University of Essex, England) Specification and Verification of Collision-Free Broadcast Networks (P. Jain and S.S. Lam, University of Texas, Austin, USA)-- Student Paper Delivery and Discrimination: The Seine Protocol (M. Gouda, University of Texas at Austin, USA; N. Maxemchuk, U. Mukherji, and K. Sabnani, AT&T Bell Laboratories, USA) 1:15 - 2:45 Session 11: Congestion and Topology Control Chair: J.J. Garcia-Luna-Aceves, SRI International An Explicit Binary Feedback Scheme for Congestion Avoidance in Computer Networks with a Connectionless Network Layer (K.K. Ramakrishnan and R. Jain, DEC, USA) Congestion Avoidance and Control (Van Jacobson, Lawrence Berkeley Laboratory, USA) A Protocol to Maintain a Minimum Spanning Tree in a Dynamic Topology (C. Cheng, I. Cimet, P. Kumar, Northwestern Univ., USA) 3:00 - 5:00 Session 12: Panel on Internet Engineering Chair: P. Gross, Mitre, USA Panelsists to be announced -------------------------------------------------------------------------- TUTORIALS August 16, 1988 9:00 am - 5:00 pm 1. INTEGRATED SERVICES DATA NETWORKS: NARROWBAND AND BROADBAND (Mario Gerla, UCLA) Abstract ISDN is one of the newest " buzzwords " in the communications arena. The concept is extremely appealing: by integrating various services ( voice, data, video etc.) in a common network we will be able to achieve lower operating costs, higher efficiency, better availability/maintainability and higher flexibility in the introduction of new services.This concept is now becoming a reality, and both users and service providers are taking into account the potential of ISDN's in formulating their plans. This seminar will review the evolution of the ISDN concept during the past few years,will discuss the standard recommendations, will compare implemen- tation alernatives and finally will report on recent field trials. In organizing this seminar , the attempt was to maintain a good balance between design principles, standard recommendations and actual network implementations. Outline - Why integrated services - Narrowband and Broadband ISDN's - Standard recommendations - ISDN backbone implementation alternatives ( Packet/Circuit/Hybrid switching) - ISDN routing and flow control - Service integration in MAN's and LAN's - Field trials - Future trends Biography Professor Mario Gerla received the PhD degree in engineering from the University of California, Los Angeles (UCLA), in 1973. From 1973 to 1976, he was Network Planning Manager at Network Analysis Corporation. From 1976 to 1977, he was with Tran Telecommunications, Los Angeles, where he participated in the development of integrated packet and circuit networks. In 1977, he joined UCLA and is now a Professor in the Department of Computer Science. His research interests include the design and control of distributed computer communications systems and networks, and the development of high-speed local area networks. 2. MULTI-HOP TOPOLOGIES, BRIDGES AND ROUTERS (Radia Perlman, DEC) Abstract A Local Area Network (LAN) allows direct communication between any stations directly connected to the LAN. Route computation and forwarding nodes are not necessary. However, technology and performance constrains the topology, distance, and number of stations of a single LAN. Thus a network usually needs to grow beyond the limits of a single LAN. One method of interconnecting LANs is through "Bridges". Two different schemes for interconnecting LANs are being standardized by two different subcommittees of the IEEE 802 committee, which is standardizing LANs. These two schemes are "spanning tree/transparent" bridges, and "source routing" bridges. Another method of creating a network with multiple links is through "routers". These too are being standardized by various committees. "Routers" perform the "Network Layer Protocol" as defined by the ISO reference model. This tutorial will briefly review the ISO reference model. It will explain the two bridge schemes, and contrast their functionality and performance. It will explain the functionality of the Network Layer, and explain design alternatives for meeting this functionality. The emphasis will be placed on the design of a "connectionless" style of Network Layer. No background other than intellectual curiosity is required. Emphasis is on protocol concepts rather than specifics of the schemes, or mathematical analysis. Outline o ISO Reference Model Review (20 minutes) o LAN review -- CSMA/CD, token ring, token bus (15 minutes) o Bridges -- Spanning Tree, Source Routing, Comparisons (1 1/2 hours) o Network Layer functionality -- connection oriented vs connectionless, routing, fragmentation and reassembly, autoconfigurability, addressing (45 minutes) o Routing Algorithms -- "Distance Vector" vs "Link State" (2 hours) o Depending on time and interest, remaining time can be spent exploring the design implications of: - interoperability of spanning tree and source routing bridges - Network Layer autoconfigurability - Design implications of hierarchical networks; subnetwork partition problem, subnetwork autonomy Biography Radia Perlman is a consulting engineer at Digital Equipment Corporation. She designed the spanning tree algorithm used by Digital's bridges and adopted for use by both bridge standards (transparent bridges and source routing bridges). She also was responsible for the design and specification of the Network Layer in Digital's Network Architecture, aspects of which have been adopted by ISO for use in the standard connectionless Network Layer. She has taught as adjunct faculty at the graduate schools of Wang Institute and University of Lowell, and at the Wang Summer Institute. She received the B.S. and M.S. degrees in mathematics at MIT, and is currently pursuing a Ph.D. degree in Computer Science at MIT. ----------------------------------------------------------------------- TUTORIAL AND SYMPOSIUM REGISTRATION Please check applicable fees: ADVANCE REGULAR (before 7/25/88) TUTORIAL 1: ____ ACM members $200 $250 ____ Non-members 250 300 ____ Full-time students** 100 150 TUTORIAL 2: ____ ACM members $200 $250 ____ Non-members 250 300 ____ Full-time students** 100 150 SYMPOSIUM*: ____ ACM members $200 $250 ____ Non-members 250 300 ____ Full-time students** 100 150 * Reception and banquet fees will be included in the recidence hall registration package. ** Student registration must be accompanied by a copy of valid full-time student ID. Must be ACM member. TOTAL PAYMENT MUST BE INCLUDED IN US$. $____________. Advance registration payment must be received by July 25, 1988. After that date, please wait to register at the Symposium itself. Make checks payable in US$ to ACM SIGCOMM. There will be a $10.00 Surcharge on foreign banks. Please return tutorial and symposium registration form and complete payment to: Dr. J.J. Garcia-Luna-Aceves, SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025, USA; tel: (415) 859-5647; e-mail: garcia@sri.com. ---------------------------------------------------------------------------- APPLICATION FOR RESIDENCE HALLS Room and meal payments are due upon arrival. DO NOT PAY IN ADVANCE. All payments must be in $US dollars, and made in cash, traveler's checks, or personal checks from a U.S. Bank made payable to Stanford University. A VERY LIMITED number of rooms in Stanford University are available on a first-come, first-served basis. Complete this form and return it, no later than July 25, 1988, to Dr. J.J. Garcia-Luna-Aceves, SRI International, Menlo Park, CA 94035; Tel: (415) 859-5647; e-mail: garcia@sri.com. RATES: PLAN I - Room for 4 nights (Mon., Tue., Wed., and Thurs.) and 10 meals from Tue. breakfast thru Fri. lunch (omitting Wed. Dinner). Single room - $102.00, shared room - $76.00 meals 95.00 meals - $95.50 ------- ------- $197.50 $171.50 per person PLAN II - Room for 3 nights (Tues., Wed., Thurs.) and 7 meals (breakfast and lunch on Wed., Thurs., Fri., and dinner on Thursday. Single room - $76.50, shared room - $57.00 meals 65.00 meals - $65.50 ------- ------- $141.50 $122.50 per person EXTRA NIGHT'S STAY: single room - $25.50, shared room - $19.00 per person. CHILDREN: 10 yrs. old and under are charged half rate for housing and meal package. RESIDENCE HALL REQUIREMENTS: Name: ____________________________________________________________ Last First Middle Address: _________________________________________________________ _________________________________________________________ _________________________________________________________ ____ Plan I, ____ Plan II ____ Single, ____ Double ____ Female, ____ Male ____ Smoking, ____ Nonsmoking Preferred rommate: ________________________________________________ Date and time of arrival: _________________________________________ Date and time of departure: _______________________________________ _________________________________________________________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1093@thumper.bellcore.com] <1988052022443500> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Proxy ARP (was Re: Dumb vs. smart host routing) Summary: AMPRNET does use ARP Message-ID: <1093@thumper.bellcore.com> Date: 20 May 88 22:44:35 GMT References: <864@kaos.UUCP> <12398059730.20.BILLW@MATHOM.CISCO.COM> <1725@pt.cs.cmu.edu> Organization: Bell Communications Research, Inc Lines: 22 > I suppose I should give Phil Karn a chance to say this first, but > AMPRnet (Amateur Packet Radio, network 44) generally won't - hidden > terminal problems and unreliable broadcast performance make it impractical. My code, written specifically for AMPRNET, does use ARP. We even have our very own officially registered "hardware type" -- see the Assigned Numbers RFC. ARP on amateur packet radio works exactly like it does on Ethernet. Lost ARP requests aren't a problem, since there'll be a retransmission (from TCP or whatever) that simply gets turned into another ARP request. There being no formal broadcast address in the AX.25 link layer protocol, however, we had to define our own -- "QST". (You hams out there will understand the significance of these letters :-)). The only complication comes when "digipeaters" are used. These are simple store-and-forward repeaters that use a source routing feature in the link protocol. Broadcasting through digipeaters doesn't work, so you have to manually enter the proper source route and destination address into your ARP table. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3374@attcan.UUCP] <1988052022491000> From: mbeast@attcan.UUCP (Michael East) Newsgroups: comp.protocols.tcp-ip Subject: 3B2/500 Enhanced TCP/IP on 3.1.1 Keywords: 3B2 500 TCP/IP 3.1.1 Message-ID: <3374@attcan.UUCP> Date: 20 May 88 22:49:10 GMT Organization: AT&T Canada Inc., Toronto Lines: 13 Help! Has anyone installed Enhanced TCP/IP WIN/3B on a 3B2/anything running UNIX* 3.1.1? I am perplexed and confused and have been unable to install it sucessfully. I seem to be missing the board drivers or something to interface to the hardware. Any help would be greatly appreciated (by e-mail please). Thanks in advance, ----- Michael B. East (mbeast) AT&T Canada Inc., Toronto {utzoo,uunet}!attcan!mbeast (416) 756-5099 There is no time like the present for postponing what you ought to be doing. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [569@drilex.UUCP] <1988052100143300> From: dricej@drilex.UUCP (Craig Jackson) Newsgroups: comp.protocols.tcp-ip,comp.sys.pyramid Subject: Slip on pyramid? Keywords: slip pyramid Message-ID: <569@drilex.UUCP> Date: 21 May 88 00:14:33 GMT Organization: Data Resources, Inc., Lexington, MA Lines: 11 Is there a slip driver for a Pyramid? Would the slip driver in the sun-spots archives (which claims to work for a 4.2 VAX, too) work on a pyramid? I'm assuming there may be some minor editing, but could you get it to work? This is for a binary-only site. I would be interested in corresponding with anybody who has gotten this to work. -- Craig Jackson UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej BIX: cjackson ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21705@amdcad.AMD.COM] <1988052101452900> From: phil@amdcad.AMD.COM (Phil Ngai) Newsgroups: comp.sys.ibm.pc,comp.protocols.tcp-ip Subject: Re: Need info on Ethernet products for the IBM AT and Sun Message-ID: <21705@amdcad.AMD.COM> Date: 21 May 88 01:45:29 GMT References: <5503@potomac.ads.com> <21681@amdcad.AMD.COM> <22166@oliveb.olivetti.com> Reply-To: phil@amdcad.UUCP (Phil Ngai) Organization: Advanced Micro Devices Lines: 16 In article <22166@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes: .In article <21681@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes: ..At present I do not believe PC-NFS works with the WD interface. I am ..using it with a (brain-damaged) 3Com interface. . .I have version 3.0 of PC-NFS and it lists the following configuration .options for the ethernet adapter: . . Western Digital WD8003E What an idiot I am! You are absolutely right, it does list it as supported. Time to throw out my 3Com and buy a WD! -- Make Japan the 51st state! I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805221402.AA28612@ucbvax.Berkeley.EDU] <1988052105004600> From: satz@CLASH.CISCO.COM Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8805221402.AA28612@ucbvax.Berkeley.EDU> Date: 21 May 88 05:00:46 GMT References: <8805190058.AA09533@FORD-COS1.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 Kevin, Someone was supposed to write up an RFC describing the mapping used for class B and C addresses. What is currently being used in the cisco DDN X.25 implementation is: class A: N.H.L.I class B: N.N.H.I class C: N.N.N.HI Where N represents the network number. H represents the PSN port number. L is the logical host field and is still zero. I is the PSN number. For class B addresses, the H field uses the unused L field. For class C addresses, the H field lies in the upper four bits of the last octet and the I field in the lower four. I don't know of anyone who has a class C PSN network. Hope this helps, Greg Satz cisco ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805211533.AA21218@uc.msc.umn.edu] <1988052115335700> From: slevy@UC.MSC.UMN.EDU ("Stuart Levy") Newsgroups: comp.protocols.tcp-ip Subject: Re: HYROUTE(TCP/IP gateway between HYPERchannel and ethernet) Message-ID: <8805211533.AA21218@uc.msc.umn.edu> Date: 21 May 88 15:33:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 If you don't use hyroute, then the hyperchannel driver will demand an IP address of the form ... (with each an 8-bit field) and then you really do need a class A net. But if you use hyroute, you can just put "direct" statements into /etc/hyroute.conf and create an arbitrary mapping of IP addresses to (loopback_code, adapter_addr, port_number, other_bits) tuples. In other words, you can use any IP addresses you wish -- they should fit just fine into a subnetted class B network. Since Crays don't do subnetting yet (in 3.0 at least, I think not in 4.0 either) you may have to use another machine as a subnet gateway, but that shouldn't be too troublesome. I know the above is true for the Cray-2 since we're actually using hyroute in this way. I'm reasonably certain that X-MP's act the same way. Stuart Levy, Minnesota Supercomputer Center slevy@uc.msc.umn.edu, (612) 626-0211 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052116545600> Received: from harvard.harvard.edu by SRI-NIC.ARPA with TCP; Sat, 21 May 88 17:53:30 PDT Received: by harvard.harvard.edu; Sat, 21 May 88 20:54:56 EDT Date: Sat, 21 May 88 20:54:56 EDT From: craig@harvard.harvard.edu To: tcp-ip@sri-nic.arpa Subject: papers on session and presentation layers Anyone know of any good papers on either the session or presentations layers? Thanks, Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12399974875.18.MURAKAMI@NTT-20.NTT.JP] <1988052120362200> From: MURAKAMI@ntt-20.ntt.jp (ken-ichiro murakami) Newsgroups: comp.protocols.tcp-ip Subject: HYROUTE(TCP/IP gateway between HYPERchannel and ethernet) Message-ID: <12399974875.18.MURAKAMI@NTT-20.NTT.JP> Date: 21 May 88 20:36:22 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 42 I have some questions about address mapping between HYPERchannel and IP address. Please let me know if you know HYROUTE mapping mechanism. We are using HYROUTE on SUN to connect hosts on HYPERchannel and hosts on ethernet by TCP/IP. We used class A IP address on Hyperchannel and class C IP address on ethernet so far. We did not obtained the class A address from SRI-NIC. This is because these hosts are isolated from our main network. Recently, we decided to connect the HYPER channel network to our main network and change the address from class A to subnetted class B which we obtained from SRI-NIC. When I asked our support engineer to change it, he told me that it was impossible to use subnetted class B address on HYPERchannel. I heard the problem was caused by HYROUTE address mapping facility. Since I could not find HYROUTE documents around me, I estimated the mapping from /etc/hosts, /etc/networks and /etc/hycf files. It seems there is no dynamic mapping between HYPERchannel address and IP address. Static mapping is employed. In addition to it, the mapping is so simple and HYPERchannel address(8bit physical address + 8bit logical address) is used as the lower 2 byte of IP address. It consumes a lot of IP address. Our network address is class B and we cannot afford to assign a lot of subnet and host address to HYPERchannel. So, I'd like to ask you the following questions; (1) Is there any way to save IP address on HYPERchannel? (2) Why does HYROUTE need class A address on HYPERchannel? (3) Where are the documents for HYROUTE and its mapping algorithm? Is it possible to get it? Thanks in advance. KEN murakami%ntt-20.ntt.jp@relay.cs.net Ken-ichiro Murakami NTT Laboratories 3-9-11, Midori-cho, Musashino-shi Tokyo, 180 Japan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052204010200> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun, 22 May 88 20:49:45 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA05040; Sun, 22 May 88 13:32:17 PDT Path: ucbvax!agate!ig!uwmcsd1!dogie!uwvax!umn-d-ub!umn-cs!mmm!brad From: mmm!brad@ucbvax.Berkeley.EDU (Brad Rhoades) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.dcom.lans,comp.unix.questions,comp.unix.wizards Subject: Ethernet packet type information requested. Keywords: Packet type, ethernet. Message-Id: <810@mmm.UUCP> Date: 22 May 88 04:01:02 GMT Distribution: usa Organization: SERC * 3M Company, St. Paul, MN Lines: 8 Posted: Sat May 21 23:01:02 1988 Apparently-To: tcp-ip@sri-nic.arpa I am interested if anyone can send me a copy of the specifications or listings of the cross-reference for ethernet type's in numeric form to the actual verbal description. The Netwatch software that displays the type of packets in numeric form for all packets and lists the names of those it knows of, but doesn't tell what all the packets are. Any info on how to obtain this would also be helpful. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12400264624.23.MKL@SRI-NIC.ARPA] <1988052206080000> From: MKL@SRI-NIC.ARPA (Mark Lottor) Newsgroups: comp.protocols.tcp-ip Subject: Gateway to Net Ten Message-ID: <12400264624.23.MKL@SRI-NIC.ARPA> Date: 22 May 88 06:08:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 53 GATEWAY TO NET TEN -- Mark Lottor [Original words and music by Jimmy Page and Robert Plant] There's a hacker who's sure all that's coax is fast and he's buying a gateway to net ten. When he gets it he'll know if the ports are all closed with a SYN he can get what he sent for. Ooh ooh ooh ooh, ooh ooh ooh ooh and he's buying a gateway to net ten. There's an RFC on the wall but he wants to be sure cause you know sometimes words have two meanings. In a note on the page there's a warning that says sometimes all of our code is broken. Don't ya know, it makes me wonder. There's an error I get when I send to the net and my packets are lost and retransmitting. In my logs I have seen loops of mail thru the machine, and the screams of those who are hacking. Oooh, it makes me wonder. And it's whispered that soon if we all fix and tune then the packets will reach their destinations. And a new day will dawn for hosts that stay long and the telnets will echo quite faster. Ohhhhh, it makes me wonder. If there's a bustle in your cisco, don't be alarmed now it's just a quick ping for the NIC machine. Yes there are two paths you can route by, but in the long haul there's still time to change the protocol. Yowwww, it makes me wonder. Your host is loaded and it will slow in case you don't know, the unix's are asking you to join them. Dear hacker, do you see the overflow, and did you know your gateway is still under development. And as we wind out more coax, and gateways slower than our hosts, There goes a message we all know, it updates routes and wants to show how everything still turns quite slow. And if you listen very hard, the bits will come to you at last. When all are ones and ones are all, to be a rubout and not a null. And he's buying a gateway to net ten... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [363@halley.UUCP] <1988052209013800> From: bc@halley.UUCP (Bill Crews) Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: Transport Level Interface Keywords: Transport Level Interface, TLI Message-ID: <363@halley.UUCP> Date: 22 May 88 09:01:38 GMT References: <349@manta.NOSC.MIL> Reply-To: bc@halley.UUCP (Bill Crews) Organization: Tandem Computers, Austin, TX Lines: 26 In article <349@manta.NOSC.MIL> gutman@manta.NOSC.MIL (Lewis M. Gutman) writes: >A month or two ago I read something about the Transport Level >Interface, being developed, I believe, at Bell Labs. My >understanding was that it offered a standard interface to >tcp. Can anyone shed any light on TLI? Can anyone suggest >a reference? If TLI is not a software interface to tcp, can >anyone tell me whether there is such a thing? Reply directly, >please. TLI is included in System V.3 from AT&T. It is a library interface for network transport services that is *very* similar to Berkeley sockets. It is thus not an interface to TCP specifically, but to any transport service. It is both very slightly better and very slightly worse than sockets. Sun has committed to supporting TLI as a part of its deal with AT&T for System V.4. I don't think anyone interprets this to mean that SunOS sockets will go away, however. TLI is often linked with Streams, since they were introduced at the same time and both deal with networking, but they are actually independent of each other. I like the SVID, Issue 2, Volume 3 presentation of TLI better than the one in the AT&T UNIX System V Network Programmer's Guide, myself. One of the X/Open books may refer to it as well; I don't remember for sure. -bc -- Bill Crews Tandem Computers bc@halley.UUCP (512) 244-8350 Austin, Texas ..!rutgers!im4u!halley!bc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [44@stanton.TCC.COM] <1988052215252700> From: donegan@stanton.TCC.COM (Steven P. Donegan) Newsgroups: comp.protocols.tcp-ip Subject: Re: connecting Internets? Summary: Request for clarification Message-ID: <44@stanton.TCC.COM> Date: 22 May 88 15:25:27 GMT References: <8805210151.AA09745@ucbvax.Berkeley.EDU> Organization: Stanton Public Domain Systems, Stanton, Ca. Lines: 24 I hope this isn't a hopelessly stupid question but: In the network I am attempting to build at my employer's site(s) we have a class B primary address 129.253.x.x and many workstations from many diverse vendors. The network backbone spans many buildings and countries via MAC level bridges. Most of the TCP/IP devices (our network is primarily XNS and DECNET) are of the SUN persuasion, one server with both MAU and thinwire interfaces, the thinwire running to 5 or 6 workstations and the MAU connecting to the backbone. The problem I have run into on a continuous basis is the situation where, even though the packets are capable of being seen by all parties, a host rejects a connection because (I think) the destination/source pair are in a different 'subnet' ie 129.253.001.x and 129.253.002.x. Is there any way under legal TCP/IP to get these blasted devices to talk to each other without buying a hardware device such as a gateway or router? I feel that the 'feature' of subnetting in my particular network is really a major LIMITATION! I have NONE of these types of problems with my XNS or DECNET devices. Help. Please, no flames for stupidity, I've been networking systems for a living for quite a while and am really interested in learning about this subject. -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805222022.AA02095@beast.DDN.MIL] <1988052220221500> From: stjohns@BEAST.DDN.MIL (Mike St. Johns) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8805222022.AA02095@beast.DDN.MIL> Date: 22 May 88 20:22:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 I'll make the official pronouncement blessing the Class B PSN mapping. This is what BRL uses and this is what we've (DDN) specified for this wierd thing called a concentrator. As far as the class C mapping, the one cisco uses is as good as any. I'd recommend you treat this as a per network split, and set it up so you can use any amount of the bits to represent host or packet switch. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052302244100> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Mon, 23 May 88 06:26:00 PDT To: "J. Kevin Rohan" cc: tcp-ip@SRI-NIC.ARPA In-reply-to: Your message of Wed, 18 May 88 18:58:51 -0600. <8805190058.AA09533@FORD-COS1.ARPA> Subject: mapping an IP address into an X.25 address Date: Mon, 23 May 88 09:04:41 -0400 From: Mike Brescia > NETINFO:X25.DOC ... covers the DDN's class A IP address The DDN (Milnet, Arpanet) x.25 service is supplied by packet switch nodes (PSNs') which have the internal structure reflected in the address given to each host attachment point. Embedded in the 14 digit address is 3 digits of PSN and 2 digits of host port connection on that PSN. Since there is this known mapping, the number of digits can be encoded uniquely in the 24 bits of 'host' of a class A IP address. > It seems like gateways everywhere support this but where's the algorithm??? The general case of any arbitrary X.25 address for a network in any country cannot be handled by a single algorithm, so the implementations that I know of have a separate data base which is typed in to the individual gateway when it is configured, or perhaps down-loaded from a file provided with the gateway. Maybe you want to specify an address resolution protocol (ARP) service where the information is stored in a single central host, instead of the ethernet style of ARP where the information for each host is stored in the individual hosts. You then only have to configure one address in each machine, the address of the ARP server. (The address of "the ARP server" on ethernet is "broadcast".) Mike Brescia ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052305592400> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Mon, 23 May 88 23:19:16 PDT Received: from AKRONVM.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 2663; Mon, 23 May 88 11:01:55 EDT Received: by AKRONVM (Mailer X1.25) id 0829; Mon, 23 May 88 10:00:13 EDT Date: Mon, 23 May 88 09:59:24 EDT From: Greg Swartwout Subject: summation of IBM internet responses To: TCP-IP@SRI-NIC.ARPA Sorry this took so long to respond, but things have been rather busy lately. Several weeks ago I asked for information, the original message is included again in case anyone missed it and might be able to help. If I get any more responses I will post them also. > We have just recently started connecting the different system here to >internet and are innterested in finding out how other sites had handled >IBM mainframes. We are particularly interested in knowing what hardware >and software has been used, and the advantages and disadvantages of each. >TCP/IP, Ethernet, and DECNET are the main protocol we are interested in. >Please respond directly to me, as I am not on all of these lists. These are most of the responses which I received. Greg Swartwout **** From: Bob Blackmun From our reading of comments on various lists, the IBM TCP/IP for VM software and the IBM 8232 to provide the channel-to-Ethernet hardware connection seem to be the consensus. **** From: Michael Hebgen <$02@DHDURZ1> Like you we are just in the process of connecting our IBM mainframes running VM and MVS to Internet via Ethernet-TCP/IP. Because there are just a few offers for the MVS site we have selected the ACS9310 box from Synelec, which runs on the VM site with the IBM TCP/IP software and on the MVS site with software provided from Synelec. The ACS-box is physically connected to the VM machine (4381) and we try to get a connection to a MAC workstation, the box for the MVS site is on order. Like you we are interested in this survey, especially in Gateways for mapping the TCP/IP applications like SMTP mail to EARN/BITNET applica- tions and vice versa. Could you please forward information on this topic if you receive one. Thanks and regards, Michael **** From: Peter Coleman At McMaster we currently use 2 Bridge CS100's to connect ethernet to our IBM Hosts. Mail is transferred via a BSC line from a Vax using JNET. We also have a DEC SNA Gateway which only talks to MVS. We have now signed a contract with IBM for an 8232 and hope to replace all Vax and Ethernet connections with it. This means that we run the 5798-FAL software in VM. This set up also provides us with the ability to let 3270 users connect from VM via ethernet to our Vaxes or using a gateway CS100 to Datapac and other external services. We use a 3Com ethernet and the 8232 will require a 3-Com card to attached to ethernet. Our main ethernet uses fibre. Peter Coleman **** From: Nick Gimbrone We find the IBM 5798-FAL (TCP/IP product for VM) to be great. Check out the comments on the IBMTCP-L@CUNYVM list. The only possible current problem is the IBM network attachment performance (better than before, but still not up to what you can do with 3rd party vendor hardware). However, there are drivers for the 3rd party vendor hardware, so it really is great stuff. :-) **** From: nowicki@Sun.COM (Bill Nowicki) Sun sells a product called CA3270 that allows a Sun to attach to an IBM Channel. We use these to talk to our mainframes, since of course we trust our own TCP and DECnet software. That is, you plug one of these into a 3/150 or 3/180, 4/280, etc. and replicate depending on load. Then run the TCP and DECnet on the Sun to act as a front end - Sun cycles are much chaper than 3090 cycles. -- WIN **** From: mqh@crnlthry.BITNET (Mike Hojnowski) For our VM systems, we use IBMs TCP/IP Program Offering (5798-FAL). There is a mailing list for that product (IBMTCP-L@CUNYVM.CUNY.EDU). If you would like more information, feel free to contact me. Mike Hojnowski Network System Programmer Cornell University **** From: ames!pacbell!belltec!lance@ucbvax.berkeley.edu Return-Path: An ex-coworker of mine has ported Berkeley 4.3 TCP to Amdahl UNIX 5.2. He is Rob Warnock in San Mateo, California. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052306093800> Received: from OFFICE-1.ARPA by SRI-NIC.ARPA with TCP; Mon, 23 May 88 09:17:05 PDT Received: from F29.Tymnet by OFFICE-1.ARPA; 23 May 88 09:15:17 PDT Received: from SLVMCL1.McAuto.Tymnet by F29.Tymnet; Mon, 23 May 88 9:11:42 PDT From: Keith R. Hacke Date: 05/23/88 11:09:38 To: tcp-ip@sri-nic.arpa Subject: DECnet-Internet Gateway Does anyone have experience with DEC's DECnet-ULTRIX V2.0 product. I understand it acts as a bidirectional DECnet-Internet gateway. I.E., it supports DECnet and Internet commands for file transfer, remote login, and mail. I have a document from DEC that show examples of using this product. It "translates" VMS commands into TCP/IP!? This is very interesting to me because I have a very large community of VMS users who wish to use the services of the DDN. But they have no TCP/IP experience. Nor do I wish them to have to buy and learn TCP/IP applications (SMTP, FTP, TELNET).I need away to route VMSmail and All-In-One mail onto the DDN, an receive DDN mail back into these DEC mail systems. If you have experience with DECnet-ULTRIX V2.0 (or later?) I would like to hear about it. Does it really allow VMS users to access services on the DDN and vice-versa? I will summarize and re-post, if response/interest in sufficient. Keith R. Hacke McDonnell Douglas - MCAIR Telecommunications 314-895-5343 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052306200000> Received: from acc.arpa by SRI-NIC.ARPA with TCP; Tue, 24 May 88 10:47:29 PDT Date: 23 May 88 14:20:00 PST From: Subject: more DDN X.25 To: "jjkkrr" cc: tcp-ip@sri-nic.arpa Reply-To: >Someone was supposed to write up an RFC describing the mapping used for >class B and C addresses. What is currently being used in the cisco DDN X.25 >implementation is: > > class A: N.H.L.I > class B: N.N.H.I > class C: N.N.N.HI > >Where N represents the network number. H represents the PSN port number. L >is the logical host field and is still zero. I is the PSN number. For class >B addresses, the H field uses the unused L field. There are people out there using the logical host field on Class A nets. >For class C addresses, >the H field lies in the upper four bits of the last octet and the I field >in the lower four. We use pretty much the same algorithm in ACC devices except that we tend to us a 3 bit IMP number and 5 bit Port number split (since IMPs can support more than 16 hosts). > I don't know of anyone who has a class C PSN network. Unless BBN has done it, we probably are the closest. We actually have a Class C number that was assigned for use by our test IMP, but we have never really used it. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [24281@pyramid.pyramid.com] <1988052308251000> From: csg@pyramid.pyramid.com (Carl S. Gutekunst) Newsgroups: comp.protocols.tcp-ip,comp.sys.pyramid Subject: Re: Slip on pyramid? Keywords: slip pyramid Message-ID: <24281@pyramid.pyramid.com> Date: 23 May 88 08:25:10 GMT References: <569@drilex.UUCP> Organization: Pyramid Technology Corp., Mountain View, CA Lines: 14 In article <569@drilex.UUCP> dricej@drilex.UUCP (Craig Jackson) writes: >Is there a slip driver for a Pyramid? It's part of the NSP option to OSx 4.4. Talk to your salescritter. If you already have Ethernet, and you upgrade to OSx 4.4, you'll get SLIP, no extra charge. >Would the slip driver in the sun-spots archives (which claims to work for >a 4.2 VAX, too) work on a pyramid? Nope. The OSx networking isn't 4.2BSD, it's 4.3. Also, if you have a multi- processor system, you have this little problem of semaphores to deal with.... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805231149.AA22588@msr.epm.ornl.gov] <1988052311490900> From: dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet packet type information requested. Message-ID: <8805231149.AA22588@msr.epm.ornl.gov> Date: 23 May 88 11:49:09 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 174 From URBANIAK@G.BBN.COM Thu Feb 5 22:10:55 1987 Received: from ORNL-MSR.ARPA by icarus.ARPA (3.2/4.9) id AA02041; Thu, 5 Feb 87 22:10:52 EST Received: by ORNL-MSR.ARPA (5.51/4.9) id AA17670; Thu, 5 Feb 87 22:07:19 EST Date: 5 Feb 1987 18:21-EST Sender: URBANIAK@G.BBN.COM Subject: Re: seeking source for Ether packet types and vendor address... From: Urbaniak@G.BBN.COM To: dunigan@ORNL-MSR.ARPA, tcp-ip@SRI-NIC.ARPA Cc: Urbaniak@G.BBN.COM, rtavilla@RCCA.BBN.COM Message-Id: <[G.BBN.COM] 5-Feb-87 18:21:17.URBANIAK> In-Reply-To: <[G.BBN.COM]27-Jan-87 17:24:31.URBANIAK> Status: R This list of Ethernet vendor addresses and Type Fields includes responses of the last week. Current BBN Ethernet and IEEE802.3 "Type" Fields The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble) consist of the "Type" or "Length" field. These are formerly assigned by Xerox, currently assigned by IEEE. Some assignments are public, others private. Information currently available includes: Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std, but not yet further documentation from IEEE; NIC RFC960; knowledge of some BBN Private Type Field values. Hex 0000-05EE IEEE802.3 Length Field 0600 Xerox NS IDP * 0800 DOD IP * # 0801 X.75 Internet 0802 NBS Internet 0803 ECMA Internet 0804 CHAOSnet 0805 X.25 Level 3 0806 ARP * (for IP and for CHAOS) 0807 XNS Compatibility 081C Symbolics Private 1000 Berkeley Trailer negotiation 1001-100F Berkeley Trailer encapsulation 1600 VALID-machine protocol? * 5208 BBN Simnet Private 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 6003 DECNET Phase IV 6004 DEC LAT 6005 DEC protocol, at interface initialization? 6006 DEC user protocol 6007 DEC cluster protocol 7001 UB NIU 7002 UB NIU 7030 Proteon 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe protocol 8006 Nestar 8010 Excelan 8035 Reverse ARP 8038 DEC LanBridge Management 803f DEC LanBridge Management 805B Stanford V Kernel, experimental 805C Stanford V Kernel, production 809B AppleTalk over Ethernet (Kinetics only?) 80f3 MacEther 9000 Loopback (Configuration Test Protocol) 9001 Bridge bridge 9003 Bridge server? FF00 BBN VITAL-LanBridge cache wakeups * These protocols use Ethernet broadcast, where multicast would be preferable. # BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3. Ethernet Vendor Addresses Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits (0-9, plus A-F, capitalized). These 12 hex digits consist of the first/left 6 digits (which should match the vendor of the Ethernet interface within the station) and the last/right 6 digits which specify the interface serial number for that interface vendor. Currently we have noted the following vendor addresses, on the BBN Corporate Ethernet. 000093 Proteon 0000AA Xerox Xerox machines 0000C0 Gould 000102 BBN BBN internal usage (not registered) 00DD00 Ungermann-Bass RT 020701 Interlan UNIBUS or QBUS machines, Proteon 02608C 3Com IBM PC; Imagen; Valid 02CF1F CMC Masscomp,palantir 080002 Bridge 080005 Symbolics Symbolics LISP machines 080009 Hewlett-Packard 080010 AT+T 080014 Excelan BBN Butterfly, Masscomp, Sil. Gra. 08001A Data General 08001E Apollo 080020 Sun Sun machines 08002B DEC UNIBUS or QBUS machines, VAXen, LANBridges (DEUNA, DEQNA, DELUA) 080041 DCA 080047 Sequent 08004C Encore 08005a IBM 9370 080068 Ridge 080086 Imagen 080089 Kinetics AppleTalk-Ethernet interface 08008B Pyramid 08008D XyVision XyVision machines AA0003 DEC Physical address for some DEC machines AA0004 DEC Logical address for systems running DECNET Ethernet addresses might be written unhyphenated (e.g. 123456789ABC), or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated by octets (e.g. 12-34-56-78-9A-BC). These addresses are physical station addresses, not multicast nor broadcast, so the second hex digit (reading from the left) will be even, not odd. At present, it is not clear how the IEEE assigns Ethernet block addresses. Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned with that block or separately. A portion of the vendor block address is reportedly assigned serially, with the other portion intentionally assigned randomly. If there is a global algorithm for which addresses are designated to be physical (in a chipset) versus logical (assigned in software), I am unaware of the algorithm. Current BBN Ethernet Multicast Addresses I do not have protocol specifications for DECNET and the VALID protocol at this time. There is no XNS or VALID router at present; those packets might be Hello packets, or gateway query packets. Ethernet Type Address Field Usage Multicast Addresses: 09-00-2B-01-00-01 8038 DEC LanBridge Hello packets 1 packet per second, sent by the lowest-addressed LanBridge 09-00-2B-01-00-0F 6004 DEC LAT 1/15s AB-00-00-01-00-00 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance AB-00-00-02-00-00 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 1 System ID packet every 8-10 minutes, by every: DEC LanBridge DEC DEUNA interface DEC DELUA interface DEC DEQNA interface (in a certain mode) AB-00-00-03-00-00 6003 DECNET Phase IV end node Hello packets 1 packet every 15 seconds, sent by each DECNET host AB-00-00-04-00-00 6003 DECNET Phase IV Router Hello packets 1 packet every 15 seconds, sent by the DECNET router AB-00-00-05-00-00 ???? Reserved DEC through AB-00-03-FF-FF-FF AB-00-04-00-00-00 ???? Reserved DEC customer private use through AB-00-04-FF-FF-FF AB-00-04-01-4D-02 6007 DECNET diskserver hello 1/5s CF-00-00-00-00-00 9000 Ethernet Configuration Test protocol (Loopback) Broadcast Address: FF-FF-FF-FF-FF-FF 0600 XNS packets, Hello or gateway search? 6 packets every 15 seconds, per XNS station FF-FF-FF-FF-FF-FF 0800 IP (e.g. RWHOD via UDP) as needed FF-FF-FF-FF-FF-FF 0806 ARP (for IP and CHAOS) as needed FF-FF-FF-FF-FF-FF 1600 VALID packets, Hello or gateway search? 1 packets every 30 seconds, per VALID station ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805231503.AA18585@ucbvax.Berkeley.EDU] <1988052313044100> From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: mapping an IP address into an X.25 address Message-ID: <8805231503.AA18585@ucbvax.Berkeley.EDU> Date: 23 May 88 13:04:41 GMT References: <8805190058.AA09533@FORD-COS1.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 > NETINFO:X25.DOC ... covers the DDN's class A IP address The DDN (Milnet, Arpanet) x.25 service is supplied by packet switch nodes (PSNs') which have the internal structure reflected in the address given to each host attachment point. Embedded in the 14 digit address is 3 digits of PSN and 2 digits of host port connection on that PSN. Since there is this known mapping, the number of digits can be encoded uniquely in the 24 bits of 'host' of a class A IP address. > It seems like gateways everywhere support this but where's the algorithm??? The general case of any arbitrary X.25 address for a network in any country cannot be handled by a single algorithm, so the implementations that I know of have a separate data base which is typed in to the individual gateway when it is configured, or perhaps down-loaded from a file provided with the gateway. Maybe you want to specify an address resolution protocol (ARP) service where the information is stored in a single central host, instead of the ethernet style of ARP where the information for each host is stored in the individual hosts. You then only have to configure one address in each machine, the address of the ARP server. (The address of "the ARP server" on ethernet is "broadcast".) Mike Brescia ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805240729.AA04882@ucbvax.Berkeley.EDU] <1988052313592400> From: R1ECGF@AKRONVM.BITNET (Greg Swartwout) Newsgroups: comp.protocols.tcp-ip Subject: summation of IBM internet responses Message-ID: <8805240729.AA04882@ucbvax.Berkeley.EDU> Date: 23 May 88 13:59:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 92 Sorry this took so long to respond, but things have been rather busy lately. Several weeks ago I asked for information, the original message is included again in case anyone missed it and might be able to help. If I get any more responses I will post them also. > We have just recently started connecting the different system here to >internet and are innterested in finding out how other sites had handled >IBM mainframes. We are particularly interested in knowing what hardware >and software has been used, and the advantages and disadvantages of each. >TCP/IP, Ethernet, and DECNET are the main protocol we are interested in. >Please respond directly to me, as I am not on all of these lists. These are most of the responses which I received. Greg Swartwout **** From: Bob Blackmun From our reading of comments on various lists, the IBM TCP/IP for VM software and the IBM 8232 to provide the channel-to-Ethernet hardware connection seem to be the consensus. **** From: Michael Hebgen <$02@DHDURZ1> Like you we are just in the process of connecting our IBM mainframes running VM and MVS to Internet via Ethernet-TCP/IP. Because there are just a few offers for the MVS site we have selected the ACS9310 box from Synelec, which runs on the VM site with the IBM TCP/IP software and on the MVS site with software provided from Synelec. The ACS-box is physically connected to the VM machine (4381) and we try to get a connection to a MAC workstation, the box for the MVS site is on order. Like you we are interested in this survey, especially in Gateways for mapping the TCP/IP applications like SMTP mail to EARN/BITNET applica- tions and vice versa. Could you please forward information on this topic if you receive one. Thanks and regards, Michael **** From: Peter Coleman At McMaster we currently use 2 Bridge CS100's to connect ethernet to our IBM Hosts. Mail is transferred via a BSC line from a Vax using JNET. We also have a DEC SNA Gateway which only talks to MVS. We have now signed a contract with IBM for an 8232 and hope to replace all Vax and Ethernet connections with it. This means that we run the 5798-FAL software in VM. This set up also provides us with the ability to let 3270 users connect from VM via ethernet to our Vaxes or using a gateway CS100 to Datapac and other external services. We use a 3Com ethernet and the 8232 will require a 3-Com card to attached to ethernet. Our main ethernet uses fibre. Peter Coleman **** From: Nick Gimbrone We find the IBM 5798-FAL (TCP/IP product for VM) to be great. Check out the comments on the IBMTCP-L@CUNYVM list. The only possible current problem is the IBM network attachment performance (better than before, but still not up to what you can do with 3rd party vendor hardware). However, there are drivers for the 3rd party vendor hardware, so it really is great stuff. :-) **** From: nowicki@Sun.COM (Bill Nowicki) Sun sells a product called CA3270 that allows a Sun to attach to an IBM Channel. We use these to talk to our mainframes, since of course we trust our own TCP and DECnet software. That is, you plug one of these into a 3/150 or 3/180, 4/280, etc. and replicate depending on load. Then run the TCP and DECnet on the Sun to act as a front end - Sun cycles are much chaper than 3090 cycles. -- WIN **** From: mqh@crnlthry.BITNET (Mike Hojnowski) For our VM systems, we use IBMs TCP/IP Program Offering (5798-FAL). There is a mailing list for that product (IBMTCP-L@CUNYVM.CUNY.EDU). If you would like more information, feel free to contact me. Mike Hojnowski Network System Programmer Cornell University **** From: ames!pacbell!belltec!lance@ucbvax.berkeley.edu Return-Path: An ex-coworker of mine has ported Berkeley 4.3 TCP to Amdahl UNIX 5.2. He is Rob Warnock in San Mateo, California. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805231435.AA08555@reason.psc.edu] <1988052314350500> From: shore@REASON.PSC.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: HYROUTE(TCP/IP gateway between HYPERchannel and ethernet) Message-ID: <8805231435.AA08555@reason.psc.edu> Date: 23 May 88 14:35:05 GMT References: <12399974875.18.MURAKAMI@NTT-20.NTT.JP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 I'm using class B addresses on a HyperChannel subnet (8 bit subnet portion) from a uVax running 4.3, but I had to tickle the device driver some. The problem was that the driver was using the host part of the address as a hash key, as was hyroute, but the kernel and library routines to get it are slightly different (the kernel strips off subnet bits - the library version doesn't). This is easily fixed, but you may be having different problems with the Sun driver. Melinda ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805231553.AA21150@oliver.cray.com] <1988052315533800> From: dab@oliver.CRAY.COM (Dave Borman) Newsgroups: comp.protocols.tcp-ip Subject: Re: HYROUTE(TCP/IP gateway between HYPERchannel and ethernet) Message-ID: <8805231553.AA21150@oliver.cray.com> Date: 23 May 88 15:53:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 54 I can proababaly answer quite a few questions about HYROUTE. First, it depends on what version of HYROUTE you are using. There have been two main versions of the HYPERchannel driver, the one written years ago at Tektronix (and distributed with 4.2BSD and 4.3BSD), and the one developed by CRAY research. The two drivers are incompattable with each other, because the Tektronix driver uses a variable size Message Proper, and the CRAY driver insists on a 64 byte Message Proper. From my experience, a lot of vendors that have HYPERchannel drivers are using the CRAY version (since there is now an RFC, #1044, that is compatable with the CRAY version) HYPERchannel does NOT have a broadcast mechanism. Therefore, if you are going to use TCP/IP over HYPERchannel, you can't use ARP, and you have to have some other method for translating IP address to HYPERchannel address. For those that do not use a HYROUTE command, the usual method is to put the 16 bit HYPERchannel address in the bottom 16 bits of the IP address. With that scheme, you can not use subnetted Class B addresses. Also, several implementations also use bits in the 3rd byte for loopback control information, hence meaning that this scheme only works with Class A addresses. I personally find this method as less than acceptable. The HYROUTE program provides the kernel with mappings between internet address and HYPERchannel addresses. Typically, it uses a hash table to speed up lookups. HYROUTE should work with Class A, B and C addresses. If you machine/driver doesn't work with all of them, complain to the vendor because the implementation is broken. For most implementations of HYROUTE, it does it's hashing, on just the host part of the address. I've been thinking long and hard on this. It can cause problems with subnets if the HYROUTE program and the kernel are not in sync with each on whether or not a network is subnetted. The HYROUTE builds the hash table and writes it into the kernel, so the kernel had better be hashing things the same way as HYROUTE or things won't work right. I'll probably be changing the CRAY UNICOS implementation of HYROUTE to hash on the entire 32 bit IP address, and then it won't matter any more whether an address is subnetted or not. The bottom line is that any implementation of HYROUTE that limits you to a subset of the IP addresses that the vendor supports is broken. (That is, if the vendor doesn't support subnets, then his HYROUTE program isn't broken because it doesn't work with subnets. But if the vendor does support subnets, as the vendor should, and HYROUTE does not work with subnets, then the vendor's implementation is broken) -Dave Borman CRAY Research, INC. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [535@interlan.UUCP] <1988052316243600> From: backman@interlan.UUCP (Larry Backman) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: FTP server question Message-ID: <535@interlan.UUCP> Date: 23 May 88 16:24:36 GMT Reply-To: backman@mercury.UUCP (Larry Backman) Distribution: na Organization: MICOM-Interlan, Boxborough, MA (1-800-LAN-TALK) Lines: 71 [] An FTP puzzle for the protocol whizes on the net. Consider the following two sniffer packets from a long trace: Packet 1 contains a FTP servers Hello message without a CR/LF. Packet 2 contains the CR/LF. RFC 959, section 4.2 of the DDN protocol handbook Page 2-773 and 2-774 clearly state: "A reply is defined to contain the 3 digit code, followed by Space , followed by one line of text (where some maximum line length has been specified), and terminated by the Telnet end of line code." At first glance, the FTP server is at fault. However, in their defense, FTP uses TCP, a stream oriented protocol, to ensure reliable delivery. This means that the data from a stream can come out as one single packet, or in the worst case, dribble out as a stream of single bytes. So in the second case, the split of the FTP message, and the TELNET CR/LF is not so bad. Needless to say, something bad happens on my end as a result; nothing that I can't hack around, but before doing so, I thought the problem was interesting enough to solicit some other opinions, Larry Backman Micom - Interlan - - - - - - - - - - - - - - - - Frame 63 - - - - - - - - - - - - - - - - - SUMMRY Delta T Destination Source Summary 63 0.0291 02070100B550 080014302203 FTP R PORT=1230 220 MIND FTP server (EXOS Version 4.5 Mon Sep 8 08... FTP: ----- FTP data ----- FTP: FTP: 220 MIND FTP server (EXOS Version 4.5 Mon Sep 8 08... FTP: ADDR HEX ASCII 0000 02 07 01 00 B5 50 08 00 14 30 22 03 08 00 45 00 .....P...0"...E. 0010 00 71 66 A9 00 00 3C 06 15 02 80 A6 80 83 80 A6 .qf...<......... 0020 81 0C 00 15 04 CE 03 12 DD C2 00 A1 51 42 50 18 ............QBP. 0030 10 00 16 27 00 00 32 32 30 20 4D 49 4E 44 20 46 ...'..220 MIND F 0040 54 50 20 73 65 72 76 65 72 20 28 45 58 4F 53 20 TP server (EXOS 0050 56 65 72 73 69 6F 6E 20 34 2E 35 20 4D 6F 6E 20 Version 4.5 Mon 0060 53 65 70 20 38 20 30 38 3A 34 31 3A 31 37 20 50 Sep 8 08:41:17 P 0070 44 54 20 31 39 38 36 29 20 72 65 61 64 79 2E DT 1986) ready. - - - - - - - - - - - - - - - - Frame 64 - - - - - - - - - - - - - - - - - SUMMRY Delta T Destination Source Summary 64 0.0001 02070100B550 080014302203 FTP R PORT=1230 <0D><0A> FTP: ----- FTP data ----- FTP: FTP: <0D><0A> FTP: ADDR HEX ASCII 0000 02 07 01 00 B5 50 08 00 14 30 22 03 08 00 45 00 .....P...0"...E. 0010 00 2A 66 AA 00 00 3C 06 15 48 80 A6 80 83 80 A6 .*f...<..H...... 0020 81 0C 00 15 04 CE 03 12 DE 0B 00 A1 51 42 50 18 ............QBP. 0030 10 00 58 00 00 00 0D 0A 30 20 4D 49 ..X.....0 MI ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805231631.AA00176@braden.isi.edu] <1988052316311700> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: LOOPBACK Net Number Message-ID: <8805231631.AA00176@braden.isi.edu> Date: 23 May 88 16:31:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 See RFC-1009, p. 15. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805232009.AA23692@ucbvax.Berkeley.EDU] <1988052318093800> From: M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA (Keith R. Hacke) Newsgroups: comp.protocols.tcp-ip Subject: DECnet-Internet Gateway Message-ID: <8805232009.AA23692@ucbvax.Berkeley.EDU> Date: 23 May 88 18:09:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 Does anyone have experience with DEC's DECnet-ULTRIX V2.0 product. I understand it acts as a bidirectional DECnet-Internet gateway. I.E., it supports DECnet and Internet commands for file transfer, remote login, and mail. I have a document from DEC that show examples of using this product. It "translates" VMS commands into TCP/IP!? This is very interesting to me because I have a very large community of VMS users who wish to use the services of the DDN. But they have no TCP/IP experience. Nor do I wish them to have to buy and learn TCP/IP applications (SMTP, FTP, TELNET).I need away to route VMSmail and All-In-One mail onto the DDN, an receive DDN mail back into these DEC mail systems. If you have experience with DECnet-ULTRIX V2.0 (or later?) I would like to hear about it. Does it really allow VMS users to access services on the DDN and vice-versa? I will summarize and re-post, if response/interest in sufficient. Keith R. Hacke McDonnell Douglas - MCAIR Telecommunications 314-895-5343 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052318210000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon, 23 May 88 19:24:15 PDT Date: 23 May 1988 22:21-EDT Sender: CERF@A.ISI.EDU Subject: Re: toothpaste From: CERF@A.ISI.EDU To: mcvax!piet@UUNET.UU.NET Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]23-May-88 22:21:31.CERF> In-Reply-To: <501@sering.cwi.nl> At one time, some nameless wag asserted that he thought TCP stood for Tom Cat Piss because it was such a powerful protocol... Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22806@bu-cs.BU.EDU] <1988052321073900> From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: FTP server question Message-ID: <22806@bu-cs.BU.EDU> Date: 23 May 88 21:07:39 GMT References: <535@interlan.UUCP> Distribution: na Organization: Boston U. Comp. Sci. Lines: 37 In-reply-to: backman@interlan.UUCP's message of 23 May 88 16:24:36 GMT > An FTP puzzle for the protocol whizes on the net. Consider the > following two sniffer packets from a long trace: > > Packet 1 contains a FTP servers Hello message without a CR/LF. > Packet 2 contains the CR/LF. ... > At first glance, the FTP server is at fault. However, in their > defense, FTP uses TCP, a stream oriented protocol, to ensure > reliable delivery. This means that the data from a stream can > come out as one single packet, or in the worst case, dribble out > as a stream of single bytes. So in the second case, the split of > the FTP message, and the TELNET CR/LF is not so bad. > Larry Backman Unless I misunderstand you there's nothing wrong with the server, it's not unusual for a system to produce such a message in two (or more) writes and each end up in its own packet, how is the underlying OS supposed to know to wait for one more write before shipping the data from the first write? (using UDP the server application might indeed have to control such behavior by buffering its own writes to "packet" boundaries [even that's only "virtual" packet boundaries, fragmentation could still show up on the wire, which sounds like what you're measuring, but should be transparent to the client], but that's not the issue here.) Your "defense" of the server is correct. Sounds like your client is imposing record boundaries on a TCP stream where it shouldn't, you should be able to read until you see CR-LF (or EOF or ERROR) w/o regard to how the data was sent. Consider it a bug in the client, possibly at the application level (ie. i bet they're assuming that the entire record will arrive in one read operation rather than looping reads until the CR-LF shows up.) -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805250611.AA25788@ucbvax.Berkeley.EDU] <1988052322200000> From: art@ACC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: more DDN X.25 Message-ID: <8805250611.AA25788@ucbvax.Berkeley.EDU> Date: 23 May 88 22:20:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The Internet Lines: 33 >Someone was supposed to write up an RFC describing the mapping used for >class B and C addresses. What is currently being used in the cisco DDN X.25 >implementation is: > > class A: N.H.L.I > class B: N.N.H.I > class C: N.N.N.HI > >Where N represents the network number. H represents the PSN port number. L >is the logical host field and is still zero. I is the PSN number. For class >B addresses, the H field uses the unused L field. There are people out there using the logical host field on Class A nets. >For class C addresses, >the H field lies in the upper four bits of the last octet and the I field >in the lower four. We use pretty much the same algorithm in ACC devices except that we tend to us a 3 bit IMP number and 5 bit Port number split (since IMPs can support more than 16 hosts). > I don't know of anyone who has a class C PSN network. Unless BBN has done it, we probably are the closest. We actually have a Class C number that was assigned for use by our test IMP, but we have never really used it. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]23-May-88.22:21:31.CERF] <1988052402210000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: toothpaste Message-ID: <[A.ISI.EDU]23-May-88.22:21:31.CERF> Date: 24 May 88 02:21:00 GMT References: <501@sering.cwi.nl> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 At one time, some nameless wag asserted that he thought TCP stood for Tom Cat Piss because it was such a powerful protocol... Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052404343200> Received: from venera.isi.edu by SRI-NIC.ARPA with TCP; Tue, 24 May 88 11:34:53 PDT Received: from braden.isi.edu by venera.isi.edu (5.54/5.51) id AA26130; Tue, 24 May 88 11:34:44 PDT Date: Tue, 24 May 88 11:34:32 PDT From: braden@venera.isi.edu Posted-Date: Tue, 24 May 88 11:34:32 PDT Message-Id: <8805241834.AA01650@braden.isi.edu> Received: by braden.isi.edu (5.54/5.51) id AA01650; Tue, 24 May 88 11:34:32 PDT To: ietf-hosts@nnsc.nsf.net, kzm@twg.com Subject: Re: multiple subnet numbers/masks on one wire? Cc: .@venera.isi.edu, ..., ...., 15:33:53, 19@venera.isi.edu, 88@venera.isi.edu, :@venera.isi.edu, , >, Address@venera.isi.edu, Date:, Did@venera.isi.edu, From:, Here@venera.isi.edu, Internet@venera.isi.edu, It@venera.isi.edu, Jeff@venera.isi.edu, Jeffrey@venera.isi.edu, Mask@venera.isi.edu, Masks@venera.isi.edu, May@venera.isi.edu, Mogul@venera.isi.edu, Mogul's@venera.isi.edu, Nothing@venera.isi.edu, PDT@venera.isi.edu, Standard., Steve@venera.isi.edu, Subject:, Subnetting@venera.isi.edu, Thu@venera.isi.edu, To:, While@venera.isi.edu, a@venera.isi.edu, after@venera.isi.edu, an@venera.isi.edu, and@venera.isi.edu, are@venera.isi.edu, aren't@venera.isi.edu, associate@venera.isi.edu, be@venera.isi.edu, braden@venera.isi.edu, but@venera.isi.edu, can@venera.isi.edu, certainly@venera.isi.edu, clarified@venera.isi.edu, complain@venera.isi.edu, connected@venera.isi.edu, day@venera.isi.edu, different@venera.isi.edu, each@venera.isi.edu, everybody@venera.isi.edu, extracts@venera.isi.edu, for@venera.isi.edu, from@venera.isi.edu, go@venera.isi.edu, host@venera.isi.edu, if@venera.isi.edu, in@venera.isi.edu, intended@venera.isi.edu, is@venera.isi.edu, it@venera.isi.edu, mechanism@venera.isi.edu, meeting@venera.isi.edu, meeting., message@venera.isi.edu, mogul@decwrl.dec.com, network@venera.isi.edu, networks@venera.isi.edu, not@venera.isi.edu, of@venera.isi.edu, our@venera.isi.edu, owner@venera.isi.edu, per-interface@venera.isi.edu, possible@venera.isi.edu, prevents@venera.isi.edu, relevant@venera.isi.edu, running@venera.isi.edu, see@venera.isi.edu, sent@venera.isi.edu, should@venera.isi.edu, single@venera.isi.edu, so@venera.isi.edu, software@venera.isi.edu, some@venera.isi.edu, standard@venera.isi.edu, standard., stored@venera.isi.edu, subnets@venera.isi.edu, subnetting@venera.isi.edu, tcp-ip@venera.isi.edu, tcp-ip@sri-nic.arpa, that@venera.isi.edu, the@venera.isi.edu, theory@venera.isi.edu, they@venera.isi.edu, this@venera.isi.edu, to@venera.isi.edu, two@venera.isi.edu, use@venera.isi.edu, vendor@venera.isi.edu, was@venera.isi.edu, we@venera.isi.edu, what@venera.isi.edu, when@venera.isi.edu, with@venera.isi.edu, wrote@venera.isi.edu, you@venera.isi.edu, your@venera.isi.edu Well, that is not quite the way the some of the other Internet old boys or the Protocol Czar remember the history. We believe the question of multiple masks was always (deliberately) vague. Jon Postel and I discussed it at length for RFC-1009, and came to the conclusion that it should be explicitly allowed. In fact, I came up with a rationale which you will find in RFC-1009. That arises from a simple computation of the addressing issues posed by the Internet growth. We now project 10**4 (subnetted) networks and 10**6 hosts in the (IP) Internet. To make that fit into subnetted class B networks, taking account of the bit lossage due to variations of campus sizes, forces one to conclude that slicing up the bits in various creative ways will be necessary to survive. There just are not enough Class B addresses to let places like Stanford have a bunch; you will HAVE to slice up 16 bits in creative ways! Now, this argument is based upon the current flat-plus-subnets IP addressing scheme. JNC was muttering about a new kind of IP address. Maybe they will come up with a new approach which will handle the expansion without multiple subnet masks, but we cannot plan on that yet. > In such an implementation, it might be possible to use different masks > for different subnets of a single network, but I would not recommend > this, since you might find that other implementations cannot handle > this; the Standard does not explicitly require that they do so. > Multiple subnet masks has no effect on hosts, only gateways, I claim. (Steve Deering's point about ICMP Address Mask Reply may be an exception). > Moreover, as it has been pointed out, there are subtle problems with > this, since in order for a host to choose the right netmask for an > outgoing packet, it has to know the self-encoding scheme as well. > I don't think this is right. I think the old mask&match game still works just fine. > If you really need a single "big" subnet and a lot of little ones, > consider getting two network numbers. I find it unlikely, however, > that a single subnet with more than a few hundred hosts on it is going > to be easily managable. No, there will not enough Class B networks 5 years from now. So, if we were to agree with Jeff : 1) all subnet masks within a (standard) network are the same, 2) conformant hosts need support only one subnet mask for an interface which connects to multiple subnets of the same IP network. But, can two different 'logical' IP networks (NOT subnets) be on the same wire ? Assuming the answer is yes, we still need a subnet mask per address, and this is another case where we have to examine the class of the IP-address rather than treat it as a flat 32-bit number divided into net/host parts by the address mask. Sorry, I don't understand why. Does anyone know if there any other "subtle problems" besides the one he cites ? For example, I've always wondered what the rules are for assigning subnet numbers and host numbers in a network with multiple subnet masks, since there's a possibility of creating duplicate IP addresses if it's not done correctly : on a Class-B network : host-x on subnet-a : mask=FFFFF000, subnet=xxxx1xxx, host=xxxxx101 host-y on subnet-b : mask=FFFFFF00, subnet=xxxx11xx, host=xxxxxx01 Keith. Of course, you HAVE to do it correctly! The simplest approach is to use the high order bits of the subnet number in a variable-length bit encoding analogous to Class A, B, C, D, and E addresses. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805242017.AA16240@ucbvax.Berkeley.EDU] <1988052408143100> From: FNTA80@BUCLLN11.BITNET ("Alain FONTAINE ", Postmaster - NAD) Newsgroups: comp.protocols.tcp-ip Subject: RFC822 routes - Thanks. Message-ID: <8805242017.AA16240@ucbvax.Berkeley.EDU> Date: 24 May 88 08:14:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 Several people (some *very* knowledgeable) did care to answer to my posting on this subject. For those who wonder, the syntax for routes in RFC822 *does* use commas (I had overlooked the fact that a '#' specification is used, which implies separation by commas ; ooops..). Several people also did care to warn me about the fact that many mailers do *not* support routes. Don't be worried. I know. I am the postmaster here, managing a copy of the Crosswell mailer, with *no* route support. But I wanted to know for sure because I am distributing an utility for VM/CMS systems to extract information from RFC822 headers, and I want it to support the full syntax. Thanks again. /AF ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052409472200> Received: from clash.cisco.com by SRI-NIC.ARPA with TCP; Tue, 24 May 88 16:50:52 PDT Received: from clash.cisco.com by clash.cisco.com with TCP; Tue, 24 May 88 16:47:25 PDT To: amdcad!phil@ucbvax.berkeley.edu (Phil Ngai) Cc: tcp-ip@sri-nic.arpa, cire@clash.cisco.com Subject: Re: Need info on Ethernet products for the IBM AT and Sun In-Reply-To: Your message of 19 May 88 18:47:53 +0000. <21681@amdcad.AMD.COM> Date: Tue, 24 May 88 16:47:22 PDT From: cire@clash.cisco.com >> Date: 19 May 88 18:47:53 GMT >> From: amdcad!phil@ucbvax.Berkeley.EDU (Phil Ngai) >> Organization: Advanced Micro Devices >> Subject: Re: Need info on Ethernet products for the IBM AT and Sun >> References: <5503@potomac.ads.com> >> Sender: tcp-ip-request@sri-nic.arpa >> To: tcp-ip@sri-nic.arpa >> >> In article <5503@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes: >> >We would like to network our IBM AT to one of our Sun Microsystems >> >computers. The ideal method is to just plug the AT into the Sun's >> >> However, with use, cracks and problems show up in PC-NFS. Some are >> real problems, some might be called a nit but anyway, the product >> could be improved. >> >> 3) ftp client blows up on mget with a small number of files, says >> "Arguments too long". >> 4) ftp client dies if you go back to telnet too long. A lot of the problems you have mentioned above but in particular 3 and 4 are a direct result of PC-NFS being built on top of MS-DOG! The FTP clint is trying to do an expansion locally but the local command parser is severally brain-dead so it pukes. The FTP client dies when you go to telnet too long because of the single threaded nature of th box. -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [895@kaos.UUCP] <1988052410330500> From: romkey@kaos.UUCP (John Romkey) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: FTP server question Message-ID: <895@kaos.UUCP> Date: 24 May 88 10:33:05 GMT References: <535@interlan.UUCP> Reply-To: romkey@kaos.UUCP (John Romkey) Distribution: na Organization: Chaos; Somerville, MA Lines: 16 Any code which uses TCP which expects TCP to preserve read()/write() chunking of data (if that's even the abstraction you're using to communicate with TCP) across the network is BROKEN. TCP doesn't preserve this information, and anything that expects it to is asking to lose very loudly. Even if the application writes a whole block of data in one write(), there may easily be conditions beyond the control or detection of the client or server that would cause the TCP to break it up into several pieces which the other side would see dribbling in as smaller parts rather than the whole block that was originally written. -- - john romkey UUCP: romkey@kaos.uucp ARPA: romkey@xx.lcs.mit.edu ...harvard!spdcc!kaos!romkey Telephone: (617) 776-3121 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052410381300> Received: from clash.cisco.com by SRI-NIC.ARPA with TCP; Tue, 24 May 88 17:41:17 PDT Received: from clash.cisco.com by clash.cisco.com with TCP; Tue, 24 May 88 17:38:15 PDT To: Norman Kincl Cc: hedrick@rutgers.edu (Charles Hedrick), tcp-ip@sri-nic.arpa, cire@clash.cisco.com Subject: Re: 802 (.2).3 TCP/IP In-Reply-To: Your message of Fri, 20 May 88 10:42:45 -0700. <509.580153365@atom> Date: Tue, 24 May 88 17:38:13 PDT From: cire@clash.cisco.com >> To: hedrick@rutgers.edu (Charles Hedrick) >> Cc: tcp-ip@sri-nic.ARPA >> Subject: Re: 802 (.2).3 TCP/IP >> Date: Fri, 20 May 88 10:42:45 PDT >> From: Norman Kincl >> >> > while ISO and DECnet phase V will presumably use 802.3. For token >> > rings, etc., that have no existing base of TCP/IP implementations, it >> > appears that only an 802.3 encapsulation will be used. So we should Whoops. That is 802.5 which has an encapsulation that is significantly different than 802.3. I am in the process of implementing this stuff for cisco. On top of the 802.5 lives 802.2 which is what I think you are really talking about. I plan on using 802.2 with the SNAP extension to allow essentialy an ethernet type field. >> > not have compatibility problems in practice. That assumes no vendors >> > get overly eager in their standard-following and try to do an 802.3 >> > encapsulation for Ethernet. HP did that, and lost obviously enough >> > that I think other vendors will be discouraged from following suit. >> cisco also implements 802.2 encapsulations for Ethernet. We use the SNAP extensions to properly identify what type the packet is. >> Are you not confusing 802.3 with 802.2? 802.3 (physical layer) is >> ... >> 802.2 (data link layer) is where the problem comes in. Though you can have >> a system that speaks both quite fluently (eg. HP9000 or cisco box), most >> systems do not do that and provide only one of those data link layers >> (usually Ethernet). Much of what was written is really talking 802.2 while saying 802.3 -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1089@aucs.UUCP] <1988052412094000> From: paul@aucs.UUCP (Paul Steele) Newsgroups: comp.protocols.tcp-ip Subject: Re: Competition for Bridge Message-ID: <1089@aucs.UUCP> Date: 24 May 88 12:09:40 GMT References: <8805171310.AA03117@tut.cis.ohio-state.edu> <3616@psuvax1.psu.edu> Reply-To: paul@aucs.UUCP (Paul Steele) Organization: School of Computer Science, Acadia Univ., Nova Scotia Lines: 10 >I have a number for Encore, but will have to track down CISCO. The number for CISCO is (415) 326-1941 or (800) 553-NETS (which doesn't work in Canada :-( ) -- Paul H. Steele USENET: {uunet|watmath|utai|garfield}!dalcs!aucs!Paul Acadia University BITNET: Paul@Acadia Wolfville, NS Internet: Paul%Acadia.BITNET@CUNYVM.CUNY.EDU CANADA B0P 1X0 (902) 542-2201x587 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052413343100> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Tue, 24 May 88 09:00:21 PDT Received: from PYTHAG.UCL.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4300; Tue, 24 May 88 04:26:53 EDT Received: by BUCLLN11 (Mailer X1.25) id 6924; Tue, 24 May 88 10:25:45 +02 Date: Tue, 24 May 88 10:14:31 +0200 From: "Alain FONTAINE (Postmaster - NAD)" Subject: RFC822 routes - Thanks. To: TCP-IP@SRI-NIC.ARPA Several people (some *very* knowledgeable) did care to answer to my posting on this subject. For those who wonder, the syntax for routes in RFC822 *does* use commas (I had overlooked the fact that a '#' specification is used, which implies separation by commas ; ooops..). Several people also did care to warn me about the fact that many mailers do *not* support routes. Don't be worried. I know. I am the postmaster here, managing a copy of the Crosswell mailer, with *no* route support. But I wanted to know for sure because I am distributing an utility for VM/CMS systems to extract information from RFC822 headers, and I want it to support the full syntax. Thanks again. /AF ----MESSAGE-END---- ----MESSAGE-BEGIN---- [AWaMApy00Uk48DIVIV@andrew.cmu.edu] <1988052414054100> From: nsb+@ANDREW.CMU.EDU (Nathaniel Borenstein) Newsgroups: comp.protocols.tcp-ip Subject: Re: SendMail Message-ID: Date: 24 May 88 14:05:41 GMT References: <8805180903.aa03398@CAD.USNA.MIL> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 It sounds like you might be interested in the Andrew Message System. AMS was designed for the Andrew File System, but also works on NFS or with no central file system. Most of it is distributed as part of the Andrew release on the X11 R2 tape from MIT. (Some parts of it haven't made it onto the R2 release, but are expected to be on the R3 release this fall.) A good overview paper about it can be found in the February, 1988 USENIX proceedings. Basically, it does just about everything you ask for and a whole lot more, including, IF you're on a high-function workstation running X11, handling multi-media mail with rasters, animations, music, and so on. For more information, especially if you can't get ahold of the USENIX paper and/or MIT release, please send mail to me or to info-andrew@andrew.cmu.edu. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805241545.AA01487@braden.isi.edu] <1988052415450000> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP server question Message-ID: <8805241545.AA01487@braden.isi.edu> Date: 24 May 88 15:45:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Unless I misunderstand you there's nothing wrong with the server, it's not unusual for a system to produce such a message in two (or more) writes and each end up in its own packet, how is the underlying OS supposed to know to wait for one more write before shipping the data from the first write? Barry, One might note, just for the record, that both the TCP protocol and most non-Berkeley implementations of TCP do in fact include a mechanism to tell the underlying OS when "to wait for one more write before shipping the data from the first write"... it called PUSH (or PSH). See RFC-793 for details. In any case, your basic point that the application level can have no knowledge of TCP packet boundaries is certainly correct. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5093@galbp.LBP.HARRIS.COM] <1988052417401100> From: mhw@wittsend..LBP.HARRIS.COM (Michael H. Warfield) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: FTP server question Message-ID: <5093@galbp.LBP.HARRIS.COM> Date: 24 May 88 17:40:11 GMT References: <535@interlan.UUCP> Sender: news@galbp.LBP.HARRIS.COM Reply-To: mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield) Distribution: na Organization: Harris/Lanier Network Knitting Circle Lines: 43 In article <535@interlan.UUCP> backman@mercury.UUCP (Larry Backman) writes: > > Packet 1 contains a FTP servers Hello message without a CR/LF. > Packet 2 contains the CR/LF. > > RFC 959, section 4.2 of the DDN protocol handbook Page 2-773 and 2-774 > clearly state: > > "A reply is defined to contain the 3 digit code, followed > by Space , followed by one line of text (where some > maximum line length has been specified), and terminated by the > Telnet end of line code." > > > At first glance, the FTP server is at fault. However, in their > defense, FTP uses TCP, a stream oriented protocol, to ensure > reliable delivery. This means that the data from a stream can > come out as one single packet, or in the worst case, dribble out > as a stream of single bytes. So in the second case, the split of > the FTP message, and the TELNET CR/LF is not so bad. > More to the point is the fact that, to an application, data on a tcp/ip connection is a structureless stream of bytes. Any structuring is imposed by a higher level (i.e. ftp client / ftp server). This implies that tcp/ip packet boundries have no significance to the application (ftp) and may not even be discernable in many implimentations. This applies even if there is a PUSH flag on the tcp/ip packet. It does not, of course, apply if an urgent flag is on the data, indicating the last byte of the packet is an URGENT boundry. But, then again, ftp does not use that flag for anything. RFC 959 concerns the ftp protocol itself and does not relate to tcp/ip packets or structuring. --- Michael H. Warfield | gatech.edu!galbp!wittsend!mhw (404)-329-8139 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it! Michael H. Warfield | gatech.edu!galbp!wittsend!mhw (404)-329-8139 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [359@lalk.excelan.UUCP] <1988052418153600> From: chuck@excelan.UUCP (Chuck Kollars) Newsgroups: comp.protocols.tcp-ip Subject: Re: connecting Internets? Message-ID: <359@lalk.excelan.UUCP> Date: 24 May 88 18:15:36 GMT References: <8805210151.AA09745@ucbvax.Berkeley.EDU> <44@stanton.TCC.COM> Reply-To: chuck@lalk.UUCP (Chuck Kollars) Organization: Excelan Inc., San Jose, CA Lines: 33 In <44@stanton.TCC.COM> donegan@stanton.TCC.COM (Steven P. Donegan) writes: > ... The problem I have run into on a continuous basis is the situation >where, even though the packets are capable of being seen by all parties, >a host rejects a connection because (I think) the destination/source >pair are in a different 'subnet' ... Is there any way under legal TCP/IP >to get these blasted devices to talk to each other without buying a >hardware device such as a gateway or router? ... If I understand your configuration correctly, you have one Class B network running on one (very large MAC-bridged) cable, with no need of subnetworking. Yet some of your nodes act like they have subnetworking enabled. Just disable subnetworking on all your nodes. Find the "address mask" or "subnetwork mask" or other such configuration value on each node, and be sure it's set to the value that means 'no subnetworking' (probably all zeros). [ex: ifconfig ie0 netmask 0] Or, maybe you are intentionally using subnetworking and have some subnetwork routers in your configuration. But sometimes two different subnetworks in fact ride on the same cable. In which case your question is how to have two IP networks on one cable. For BSD and most BSD-derived implementations, the answer is to add a route entry for the "other" subnetwork with a metric of 0 hops. Do this to every node. The metric value 0 hops is interpreted to mean 'on the same cable'. [ex: route add 129.253.2.0 129.253.0.99 0] (Of course, the purist rule is "ONE IP (sub)network <-> ONE cable". So convince yourself that you don't have an address administration problem before you start hacking.) -- Chuck Kollars, Excelan, Inc. mtxinu!excelan!chuck@ucbvax.Berkeley.COM (chuck@excelan.UUCP) ...!{mtxinu,leadsv,cae780}!excelan!chuck ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805242027.AA08675@devvax.TN.CORNELL.EDU] <1988052420265300> From: jch@DEVVAX.TN.CORNELL.EDU (Jeffrey C Honig) Newsgroups: comp.protocols.tcp-ip Subject: Re: Proteon's behaviour Message-ID: <8805242027.AA08675@devvax.TN.CORNELL.EDU> Date: 24 May 88 20:26:53 GMT References: <880519-134446-6569@Xerox> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Call Proteon customer service (617/898-3100) and request a boot load with the test disabled. Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805251414.AA01829@ucbvax.Berkeley.EDU] <1988052500381300> From: cire@CLASH.CISCO.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: 802 (.2).3 TCP/IP Message-ID: <8805251414.AA01829@ucbvax.Berkeley.EDU> Date: 25 May 88 00:38:13 GMT References: <509.580153365@atom> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 45 >> To: hedrick@rutgers.edu (Charles Hedrick) >> Cc: tcp-ip@sri-nic.ARPA >> Subject: Re: 802 (.2).3 TCP/IP >> Date: Fri, 20 May 88 10:42:45 PDT >> From: Norman Kincl >> >> > while ISO and DECnet phase V will presumably use 802.3. For token >> > rings, etc., that have no existing base of TCP/IP implementations, it >> > appears that only an 802.3 encapsulation will be used. So we should Whoops. That is 802.5 which has an encapsulation that is significantly different than 802.3. I am in the process of implementing this stuff for cisco. On top of the 802.5 lives 802.2 which is what I think you are really talking about. I plan on using 802.2 with the SNAP extension to allow essentialy an ethernet type field. >> > not have compatibility problems in practice. That assumes no vendors >> > get overly eager in their standard-following and try to do an 802.3 >> > encapsulation for Ethernet. HP did that, and lost obviously enough >> > that I think other vendors will be discouraged from following suit. >> cisco also implements 802.2 encapsulations for Ethernet. We use the SNAP extensions to properly identify what type the packet is. >> Are you not confusing 802.3 with 802.2? 802.3 (physical layer) is >> ... >> 802.2 (data link layer) is where the problem comes in. Though you can have >> a system that speaks both quite fluently (eg. HP9000 or cisco box), most >> systems do not do that and provide only one of those data link layers >> (usually Ethernet). Much of what was written is really talking 802.2 while saying 802.3 -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1106@thumper.bellcore.com] <1988052505313800> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: FTP server question Summary: but the server's TCP isn't exactly kosher either Message-ID: <1106@thumper.bellcore.com> Date: 25 May 88 05:31:38 GMT References: <535@interlan.UUCP> <22806@bu-cs.BU.EDU> Distribution: na Organization: Bell Communications Research, Inc Lines: 8 While it is certainly true that a client that expects any sort of relationship between TCP segments and logical messages is broken, I wouldn't let the server get off the hook that easily. Why should it take two packets to send what should go in one? In this, the first year AJ (After Jacobson) I would think people would be a little more aware of such inefficient TCP behavior. :-) Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052507563600> Received: from NNSC.NSF.NET ([128.89.0.78]) by SRI-NIC.ARPA with TCP; Wed, 25 May 88 13:35:07 PDT Received: by NNSC.NSF.NET id ab12518; 25 May 88 14:49 EDT To: tcp-ip@sri-nic.ARPA Subject: timezones in 822 Date: Wed, 25 May 88 14:36:36 -0400 From: Craig Partridge Hi folks, I recall seeing a message on either tcp-ip or header-people a few months back to the effect that the military timezones specified in RFC 822 were wrong. I am now unable to find the message. A note to header-people failed to shake it loose. Perhaps some kind soul on TCP-IP could describe the problem to me again? Thanks, Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805251506.AA03903@mitre.arpa] <1988052515062300> From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: comp.protocols.tcp-ip Subject: Re: multiple subnet numbers/masks on one wire? Message-ID: <8805251506.AA03903@mitre.arpa> Date: 25 May 88 15:06:23 GMT References: <8805241834.AA01650@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 14 Bob - that was an incredible "Cc:" address list on your note - 36 lines. Some of the more interesting/obscure ones were: .::., 33:53@15, :@venera.isi.edu, , >, Mogul@venera.isi.edu, Mogul's@venera.isi.edu, mogul@decwrl.dec.com, This fellow 'mogul' probably doesn't have time to do anything but read mail. Regards - Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805251538.AA07658@windsor.cray.com] <1988052515384600> From: hrp@windsor.CRAY.COM (Hal Peterson) Newsgroups: comp.protocols.tcp-ip Subject: LOOPBACK Net Number Message-ID: <8805251538.AA07658@windsor.cray.com> Date: 25 May 88 15:38:46 GMT References: <12399897330.45.MKL@SRI-NIC.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Hmmmm. Isn't RFC 1009 an obscure place for this information, which is relevant to many of us who never need to see the inside of a gateway? This deserves mention in "Assigned Numbers," and perhaps in "Address Mappings" as well, and certainly in the forthcoming "Requirements for Internet Hosts" RFC. Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-3145 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805251558.AA02602@braden.isi.edu] <1988052515581900> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP server question Message-ID: <8805251558.AA02602@braden.isi.edu> Date: 25 May 88 15:58:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 It does not, of course, apply if an urgent flag is on the data, indicating the last byte of the packet is an URGENT boundry. But, then again, ftp does not use that flag for anything. Hmmm. I think you are wrong about the last. The abort sequence on the top of page 35 of RFC-959 specifies a Telnet IP - Synch sequence, and the Telnet protocol spec says that this is to be sent with Urgent. So, by implication, a (correctly implemented) FTP does use the TCP Urgent pointer (not a flag!). Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805260153.AA13746@ucbvax.Berkeley.EDU] <1988052518363600> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: timezones in 822 Message-ID: <8805260153.AA13746@ucbvax.Berkeley.EDU> Date: 25 May 88 18:36:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Hi folks, I recall seeing a message on either tcp-ip or header-people a few months back to the effect that the military timezones specified in RFC 822 were wrong. I am now unable to find the message. A note to header-people failed to shake it loose. Perhaps some kind soul on TCP-IP could describe the problem to me again? Thanks, Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [CMM.0.86.580588711.dbd@vx2.GBA.NYU.EDU] <1988052518383100> From: dbd@VX2.GBA.NYU.EDU (Daniel B Dobkin) Newsgroups: comp.protocols.tcp-ip Subject: VMS <--> IBM connection Message-ID: Date: 25 May 88 18:38:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 Here's another of those frequently asked questions; trouble is, the information changes almost as frequently.... We are a large VAX/VMS shop looking for a way to communicate with our IBM mainframes (MVS). We've looked quite seriously at the FLEXlink product; what I need now is to hear from ANYONE with experience with this product -- anything at all, from war stories to "couldn't live without it" and whatever's in between. (For those who don't know, FLEXlink software provides file transfer, terminal emulation, and task-to-task capabilites through special hardware that sits between a VAX and an IBM system.) I'd also like to hear from anyone who's used (or is familiar with) ACC's TCP/IP package for MVS. Are there advantages/disadvantages to using TCP v. FLEXlink? (Yes, some are obvious.) Please reply directly to me -- I'll be glad to summarize whatever I get back. thanks, \dbd Irving Trust Co. dbd@gba.nyu.edu (212) 815 3712 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2773@umd5.umd.edu] <1988052519374700> From: hans@umd5.umd.edu (Hans Breitenlohner) Newsgroups: comp.protocols.tcp-ip Subject: Re: Proteon's behaviour Message-ID: <2773@umd5.umd.edu> Date: 25 May 88 19:37:47 GMT References: <880519-134446-6569@Xerox> Reply-To: hans@umd5 (Hans Breitenlohner) Organization: University of Maryland, College Park Lines: 20 In article <880519-134446-6569@Xerox> Burrell.osbunorth@Xerox.COM, castillo.osbunorth@Xerox.COM writes: > >We have noticed some behaviour which seems to be a normal operation on the >gateway, but that it is very annoying. >It seems that the Proteon does some self testing of both of its Ethernet >interfaces and other internal hardware by sending small trash packets to itself >every so often through both interfaces. >The frequency of such tests is often enough that it is noticibly consuming >precious bandwidth already at a premium in our backbone which is carrying a lot >of XNS traffic. > Two packets are sent out every 3.5 to 4 seconds. While this can be annoying in many respects, it is hard to see how this could consume much bandwidth. You can order the software with this feature ("maintenance feature") disabled, on a per interface basis. You should know that, if you do so, you lose the ability of the gateway to determine if the attached ethernet works. As a result it may RIP-advertise reachability of attached subnets when they are actually down. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805251956.AA01227@MACOM3.ARPA] <1988052519565200> From: woody@MACOM3.ARPA (robert a woodburn) Newsgroups: comp.protocols.tcp-ip Subject: EGP Message-ID: <8805251956.AA01227@MACOM3.ARPA> Date: 25 May 88 19:56:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Can someone provide some general statistics about EGP's operation at their site. I'm trying to compile some statistics about average update sizes and frequency to compare with a protocol being worked on here. If anyone already has such figures could you please send me something representative of the data? Thanks Much... wood y ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4776@orstcs.CS.ORST.EDU] <1988052520384600> From: hakanson@mist.cs.orst.edu (Marion Hakanson) Newsgroups: comp.protocols.tcp-ip Subject: Re: subnetting supported by Sequents? Message-ID: <4776@orstcs.CS.ORST.EDU> Date: 25 May 88 20:38:46 GMT References: <18969@watmath.waterloo.edu> Sender: netnews@orstcs.CS.ORST.EDU Reply-To: hakanson@mist.CS.ORST.EDU (Marion Hakanson) Organization: Oregon State University - CS - Corvallis, Oregon Lines: 31 I hope this is of general interest.... We are running DYNIX 3.0.4 on a Sequent B21, and it does indeed support subnets (and a settable broadcast address). According to the people at Sequent, they put in the 4.3bsd IP networking code, but are still running the 4.2bsd TCP code (why, I don't know). This means that any 4.3bsd systems you have must be configured with the TCP_COMPAT_42 hack (TCP sequence number bug). It also includes the 4.3bsd routed and RIP code. Other than the fact that DYNIX 3.0 does not include a nameserver (or MX-speaking sendmail), and that it still runs the buggy 4.2bsd ftp, telnet and rlogin implementations, along with the other 4.2bsd TCP performance bugs, our Sequent functions adequately as an Internet site (behind a Cisco router). The only annoyance I really notice is that sendmail has the "loop on EOF" bug if an Internet SMTP connection is lost during a mail transfer (this can be fixed when we port the 4.3bsd sendmail.MX). Rick Adams at UUNET may be of help to you, as well. The UUNET machine is also a Sequent B21 running DYNIX 3.0. Don't let my criticisms put you completely off of the machine. It is very solid, no crashes, and has a tremendous amount of CPU bandwidth (by that, I meant it's very hard to slow the thing down, especially if you have enough RAM). But if we didn't have a 4.3bsd machine to handle nameservice and mail routing, we'd be up a creek. In short, it ain't 4.3. -- Marion Hakanson Domain: hakanson@cs.orst.edu CSNET : hakanson%cs.orst.edu@relay.cs.net UUCP : {hp-pcd,tektronix}!orstcs!hakanson ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805252159.AA02968@bel.isi.edu] <1988052521594300> From: postel@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: LOOPBACK Net Number Message-ID: <8805252159.AA02968@bel.isi.edu> Date: 25 May 88 21:59:43 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 Hal Peterson: See "Internet Numbers" RFC-997 page 5. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805252220.AA03042@braden.isi.edu] <1988052522203100> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: LOOPBACK Net Number Message-ID: <8805252220.AA03042@braden.isi.edu> Date: 25 May 88 22:20:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Hmmmm. Isn't RFC 1009 an obscure place for this information, which is relevant to many of us who never need to see the inside of a gateway? This deserves mention in "Assigned Numbers," and perhaps in "Address Mappings" as well, and certainly in the forthcoming "Requirements for Internet Hosts" RFC. Well, when it comes to Internet numbers, I only do what I am told (Jon Postel is my boss). However, perhaps I misled you. If you will turn to the latest Internet Numbers RFC, RFC-1020, you will find the loopback address defined. Jon mumbled that he plans to move the special-number rules back to the Assigned Numbers RFC. So, yes, you are right. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805252232.AA01717@acetes.dec.com] <1988052522320000> From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: multiple subnet numbers/masks on one wire? Message-ID: <8805252232.AA01717@acetes.dec.com> Date: 25 May 88 22:32:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 This fellow 'mogul' probably doesn't have time to do anything but read mail. Regards - Craig How right you are ... fortunately, the host where I read my mail was down all morning, so I got some work done. (Less fortunately, all those messages addressed to whatever@venera.isi.edu must have ended up back in Bob's mailbox, since I don't have a mailbox at ISI.) Ah, the risks of the REPLY command. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1326@uw-nsr.UUCP] <1988052523581800> From: john@uw-nsr.UUCP (John Sambrook) Newsgroups: comp.protocols.tcp-ip Subject: Re: Honeywell and DG Message-ID: <1326@uw-nsr.UUCP> Date: 25 May 88 23:58:18 GMT References: <8805122012.AA13251@brillig.umd.edu> Reply-To: john@uw-nsr.UUCP (John Sambrook 548-4386) Organization: UW-Bioengineering, Seattle, WA Lines: 31 >In article <8805091745.AA24461@ACC-SB-UNIX.ARPA> chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) writes: >Good morning all! > I am going to be running Honeywell and Data General systems on a >LAN soon and have been told by a customer that they have TCP/IP implement- >ations running on them. > We are running DG/UX 3.11.1 and have DG/UX TCP/IP installed. I believe the product is derived from 4.2BSD (not 4.3) so it may have some of the bugs that were present in that release. However, Data General seems to update it fairly frequently so I imagine reported bugs would be fixed in a reasonable length of time. It works fine, modulo the following limitations: 1. No support for using nameservers or resolvers. You have to (try to) maintain an up-to-date copy of /etc/hosts. Not at all easy these days. 2. The ping program says one of two things: "xxx is alive" or "no answer from xxx." To be fair, I think that some of these will be fixed at the next major TCP/IP release (coinciding with DG/UX 4.0). Hope this helps. -- John Sambrook Internet: john@nsr.bioeng.washington.edu University of Washington RC-05 UUCP: uw-nsr!john Seattle, Washington 98195 Dial: (206) 548-4386 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1488@nrcvax.UUCP] <1988052602324200> From: jt@nrcvax.UUCP (Jerry Toporek) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: FTP server question Message-ID: <1488@nrcvax.UUCP> Date: 26 May 88 02:32:42 GMT References: <535@interlan.UUCP> Reply-To: jt@minnie.UUCP (Jerry Toporek) Distribution: na Organization: Network Research Corp. Oxnard, CA Lines: 22 In article <535@interlan.UUCP> backman@mercury.UUCP (Larry Backman) writes: > [...] > At first glance, the FTP server is at fault. However, in their > defense, FTP uses TCP, a stream oriented protocol, to ensure > reliable delivery. This means that the data from a stream can > come out as one single packet, or in the worst case, dribble out > as a stream of single bytes. So in the second case, the split of > the FTP message, and the TELNET CR/LF is not so bad. > > Needless to say, something bad happens on my end as a result; nothing > that I can't hack around, but before doing so, I thought the problem > was interesting enough to solicit some other opinions, You got it all right. Any piece of stream-based software that makes any assumption about what it is going to get back from a read is asking for trouble. -- ====================================== `` '' =============================== Jerry Toporek <`@-@'> Network Research Corp. ( > ) 1620 Federal Ave. #2 jt@NRC.COM \~/ LA, CA, 90025, USA jt@nrcvax.UUCP (213) 479-6436 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805252319.aa17134@CAD.USNA.MIL] <1988052603194500> From: tcs@USNA.MIL (Terry Slattery) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dumb vs. smart host routing Message-ID: <8805252319.aa17134@CAD.USNA.MIL> Date: 26 May 88 03:19:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 > Second, the software should have the list of default gateways that I keep > bringing up rather than just one. The folks at BRL have done just that in some user mode software that they cooked up during the times when RIP was still being developed. They ping the list of gateways with a long time constant to get a metric on which ones are up and what the error rate is to them. (Remember, this is only done on the local network where the ping loading is deemed necessary to support the dynamic reconfiguration.) If the primary gateway goes down, the user mode process performs a system call (Unix 4.2/3) to change the default route to one of the secondary gateways. The primary gateway is still pinged. When it comes back up (or the loss rate becomes acceptable), the pings are increased in frequency to get a better indication of the link's operation. If everything still looks good, the kernel is told to switch back to the primary gateway. This type of dynamic routing could be put to good use in systems like the Excelan VMS product. -tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4962@batcomputer.tn.cornell.edu] <1988052605341300> From: garry@batcomputer.tn.cornell.edu (Garry Wiegand) Newsgroups: comp.os.misc,comp.os.vms,comp.graphics,comp.lang.misc,comp.windows.misc,comp.protocols.tcp-ip,soc.singles,news.misc Subject: "HELP ME" - Rip-off warning Message-ID: <4962@batcomputer.tn.cornell.edu> Date: 26 May 88 05:34:13 GMT Reply-To: garry@oak.cadif.cornell.edu Followup-To: news.misc Organization: Cornell Engineering && Ithaca Software, Inc. Lines: 10 Chances are greater than zero that "Jay-jay" is a mail fraud: no name was signed to the posting, the net address (if it's valid) isn't at the U of Nebraska, cash money, no checks, was requested, and no street address was given (Jay-jay has an anonymous PO Box). I may have an unkind mind, but there's a bad smell rising here. Followups to news.misc only, PLEASE. Keep your dollars in your pockets. garry wiegand (garry@oak.cadif.cornell.edu - ARPA) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052606100000> Received: from G.BBN.COM ([8.2.0.18]) by SRI-NIC.ARPA with TCP; Thu, 26 May 88 07:12:08 PDT Date: 26 May 1988 10:10-EDT Sender: CLYNN@G.BBN.COM Subject: Re: FTP server question From: CLYNN@G.BBN.COM To: galbp!wittsend..LBP.HARRIS.COM!mhw@GATECH.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]26-May-88 10:10:07.CLYNN> In-Reply-To: <5093@galbp.LBP.HARRIS.COM> Re: "last byte of a packet is an URGENT boundary" The TCP URGENT mechanism uses a pointer; I do not think that there is any specification which says that packet boundaries are significant with respect to URGENTs. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052609100000> Received: from twg.com by SRI-NIC.ARPA with TCP; Thu, 26 May 88 18:14:28 PDT Received: from TWG.COM by twg.com with SMTP ; Thu, 26 May 88 17:46:44 PST Received: from vax1.twg.com by Gonzo.TWG.COM id aa00253; 26 May 88 17:43 PDT Date: 26 May 88 17:10:00 PST From: "Miller, Grant" Subject: Mailing Lists To: tcp-ip TCP-IP@sri-nic.arpa Please provide mailing list info at earliest convenience. miller@twg.com Grant Miller The Wollongong Group 1129 San Antonio Rd. Palo Alto, CA 94303 415-962-7207 If I have the wrong mail address please disregard.  ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM]26-May-88.10:10:07.CLYNN] <1988052614100000> From: CLYNN@G.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP server question Message-ID: <[G.BBN.COM]26-May-88.10:10:07.CLYNN> Date: 26 May 88 14:10:00 GMT References: <5093@galbp.LBP.HARRIS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 Re: "last byte of a packet is an URGENT boundary" The TCP URGENT mechanism uses a pointer; I do not think that there is any specification which says that packet boundaries are significant with respect to URGENTs. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805261504.AA27649@beno.CSS.GOV] <1988052615044700> From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: subnetting supported by Sequents? Message-ID: <8805261504.AA27649@beno.CSS.GOV> Date: 26 May 88 15:04:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 If you bitch and scream loudly enough, Sequent will send you a special version of TCP. Its not as good as the latest Jacobsen/Karels TCP, but it is a tremendous improvement over what they were shipping. I think it will be included as part of the next real release. They do still ship the broken 4.2bsd user programs and don't seem to care. The good news is that the 4.3bsd source programs port rather easily. We are running the latest bind and sendmail on our Sequent and it performs quite well. It is important to keep yelling at Sequent until they fix it. They think that their customers don't care about things like high performance networking. If enough sites keep complaining, they might finally fix things. --rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052615205000> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Fri, 27 May 88 03:55:13 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA04991; Thu, 26 May 88 17:53:27 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 May 88 15:20:50 GMT From: execu!dewey@cs.utexas.edu (dewey henize) Organization: Execucom Systems Corp. Subject: Getting started Message-Id: <192@execu.EXECU> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Ok, I'm obviously the slow one here, but... For some of us, this world of TCP/IP and networking is a bit tough to pick up. I didn't have a chance to learn about it in college so its been strictly OJT. Would anyone else out there who has been in this position be willing to send or post a good solid intro to mid level reading list? So far I've gotten along alright, but a lot of what I'm doing smacks of black magic instead of systems administration. I'm SURE there is a reason for most of this, and I can't help but believe I can learn it if there is just some source of this info. All the same applies to uucp and similiar problems. L.sys and cousins just plain confuse me, I don't know how this stuff manages to work together and I really would prefer to be able to contribute eventually rather than just skim off the top of others knowledge. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805261543.AA28102@beno.CSS.GOV] <1988052615433000> From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: LOOPBACK Net Number Message-ID: <8805261543.AA28102@beno.CSS.GOV> Date: 26 May 88 15:43:30 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 If it's an "official" number, why doesn't it appear in hosts.txt and the domain servers? It would save a lot of people the hassle of configuring it in their local systems as a special case. --rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22924@bu-cs.BU.EDU] <1988052615445400> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Proteon's behaviour Summary: Keep the test alive Message-ID: <22924@bu-cs.BU.EDU> Date: 26 May 88 15:44:54 GMT References: <880519-134446-6569@Xerox> <2773@umd5.umd.edu> Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.tcp-ip Organization: Boston Univ. Information Tech. Dept. Lines: 27 In article <2773@umd5.umd.edu> hans@umd5 (Hans Breitenlohner) writes: >In article <880519-134446-6569@Xerox> Burrell.osbunorth@Xerox.COM, castillo.osbunorth@Xerox.COM writes: >> >>It seems that the Proteon does some self testing of both of its Ethernet >>interfaces and other internal hardware by sending small trash packets to itself >>every so often through both interfaces. > >Two packets are sent out every 3.5 to 4 seconds. While this can be annoying >in many respects, it is hard to see how this could consume much bandwidth. > >You can order the software with this feature ("maintenance feature") disabled, >on a per interface basis. >You should know that, if you do so, you lose the ability of the gateway to >determine if the attached ethernet works. As a result it may RIP-advertise >reachability of attached subnets when they are actually down. If the router does not have a hardware interface test capability, it's a pain when the interface doesn't work. Without a test, it can't even detect a missing xcvr cable. I think you should value the interface test. What Proteon has done is essentially the ONLY way to do a thorough test of an Ethernet interface that can't listen to its own transmissions. All software based tests are only indicators. If you disable the test, you have a black hole until you manually disable the interface. Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805261405.aa11587@Huey.UDEL.EDU] <1988052618050900> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: PING with source/record route Message-ID: <8805261405.aa11587@Huey.UDEL.EDU> Date: 26 May 88 18:05:09 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Peter, The original PING (Packet Inter-Net Groper) was written for the fuzzball circa 1980 and is still in use, although continuously modified, hacked and abused. I don't think you want that program, which is written in PDP11 assembler and is full of trap doors, Trojan horses and covert channels (the IP sequence number is really the local millisecond clock, tra la, tra la). What you probably do want is the Unix PING last heard from BRL. Track down Mike Minnich (minnich@udel.edu), who has hacked the BRL version to include record-route and other gizmos. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12741@shemp.CS.UCLA.EDU] <1988052618462500> From: wales@valeria.cs.ucla.edu (Rich Wales) Newsgroups: comp.protocols.tcp-ip Subject: Re: timezones in 822 Message-ID: <12741@shemp.CS.UCLA.EDU> Date: 26 May 88 18:46:25 GMT References: <8805260153.AA13746@ucbvax.Berkeley.EDU> Sender: news@CS.UCLA.EDU Reply-To: wales@CS.UCLA.EDU (Rich Wales) Organization: UCLA CS Department, Los Angeles Lines: 32 In article <8805260153.AA13746@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes: I recall seeing a message on either tcp-ip or header-people a few months back to the effect that the military timezones specified in RFC 822 were wrong. I am now unable to find the message. A note to header-people failed to shake it loose. Perhaps some kind soul on TCP-IP could describe the problem to me again? With pleasure. On page 26 of RFC822 (Section 5.1), the single-letter military time zone designations are defined with the wrong sign. For example, "A" is said to be "-1" (i.e., 1 hour west of UT/GMT), while "N" is said to be "+1" (i.e., 1 hour east of UT/GMT). The *correct* definition is as follows: East of UT/GMT: A = +1; B = +2; ...; M = +12 (note that "J" is not used) West of UT/GMT: N = -1; O = -2; ...; Y = -12 UT/GMT itself: Z = 0 Thus, for example, Pacific Daylight Time in North America can be repre- sented in RFC822 as "PDT", "-0700", or "T" (*not* "G"). -- Rich Wales // UCLA CS Dept // wales@CS.UCLA.EDU // +1 (213) 825-5683 3531 Boelter Hall // Los Angeles, California 90024-1596 // USA ...!(ucbvax,rutgers)!ucla-cs!wales ...!uunet!cs.ucla.edu!wales "Zounds! A Gorkon death station appears! Evasive action!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805261504.aa12350@Huey.UDEL.EDU] <1988052619041500> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: timezones in 822 Message-ID: <8805261504.aa12350@Huey.UDEL.EDU> Date: 26 May 88 19:04:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 Craig, There is only one time zone in the cosmos and that is UT (nee GMT). There is only one clock in the cosmos and it speaketh UT. All other timezones are false gods and have meaning only to local holy men. In Saudi Arabia it is said that midnight occurs at local sundown. In Bombay and parts of Australia the time zones are on the half-hour and in at least one spot they are on the quarter hour. And then we get to talk about summer/winter time. Those of you who know me have heard this view on a few prior occasions. Oh yes, the Supreme Clock speaks time in 24-hour format and adds a 61st second 14 times in the last 16 years. If I set my clock back 1431 days, what time is it in Sydney? What day? Ponder before answering. If I write a contract on Blenheim Reef to expire precisely on 1 January 2000 how long, precisely, is it in force? Let's assume a leap-second is inserted on the previous day. Assume the contract expires based on local London time. Your answer? Yeah, I remember a very old message that complained an RFC-822 time zone was bogus, one of the European zones, I believe. There are at least a couple of Navy chaps watching these frequencies that should have the answer. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805261929.AA04199@RHEA.CAM.UNISYS.COM] <1988052619291400> From: jonab@CAM.UNISYS.COM (Jonathan P. Biggar) Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP server question Message-ID: <8805261929.AA04199@RHEA.CAM.UNISYS.COM> Date: 26 May 88 19:29:14 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 Re: "last byte of a packet is an URGENT boundary" The TCP URGENT mechanism uses a pointer; I do not think that there is any specification which says that packet boundaries are significant with respect to URGENTs. Not so! RFC 793 states: If there is urgent data the user will have been informed as soon as it arrived via a TCP-to-user signal. The receiving user should thus be in "urgent mode". If the URGENT flag is on, additional urgent data remains. If the URGENT flag is off, this call to RECEIVE has returned all the urgent data, and the user may now leave "urgent mode". *****Note that data following the urgent pointer (non-urgent data) cannot be delivered to the user in the same buffer with preceeding urgent data unless the boundary is clearly marked for the user.***** MIL-STD 1778 has similar language. Jon Biggar jonab@cam.unisys.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805262025.AA26751@csc-lons.ARPA] <1988052620250000> From: scottr@CSC-LONS.ARPA (Scott W. Rogers) Newsgroups: comp.protocols.tcp-ip Subject: INFO on TCP/IP & Domain Name Server for Honywell DPS-8. Message-ID: <8805262025.AA26751@csc-lons.ARPA> Date: 26 May 88 20:25:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: Computer Sciences Corporation. Lines: 11 In search of information: Does anyone have information on, or a port of, the domain name server (bind) for Honywell TCP/IP on a DPS-8 (H 6000) running GCOS 8 (release SR3000). Also, I would appreciate hearing from anyone currently running this software on the Internet. Thanks in advance, ------------------------------------------------------------------------ Scott W. Rogers Computer Sciences Corporation - Systems Division AT&T: (703) 876-1363 3160 Fairview Park Dr. - Falls Church, VA 22152 Fax: (703) 876-4072 Internet: scottr@csc-lons.ARPA ------------------------------------------------------------------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805262102.AA16497@columbia-pdn] <1988052621021500> From: rms%columbia-pdn@ACC-SB-UNIX.ARPA (Ron Stoughton acc_gnsc) Newsgroups: comp.protocols.tcp-ip Subject: reckless TCP packets Message-ID: <8805262102.AA16497@columbia-pdn> Date: 26 May 88 21:02:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Today a driver entered from an on-ramp at 75 MPH, swerved in front of me across two lanes of traffic, and raced on down the freeway. His license number was TCP 810. I guess it was an urgent packet. Ron Stoughton, ACC rms@acc-sb-unix.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052621375800> Received: from Xerox.COM by SRI-NIC.ARPA with TCP; Thu, 26 May 88 14:47:58 PDT Received: from Salvador.ms by ArpaGateway.ms ; 26 MAY 88 14:38:29 PDT Date: 26 May 88 21:37:58 GMT (Thursday) Subject: Re: timezones in 822 In-reply-to: craig's message of Wed, 25 May 88 14:36:36 -0400 To: Craig Partridge cc: tcp-ip@sri-nic.ARPA, RMRichardson.PA@Xerox.COM From: Rich Line-fold: no Message-ID: <880526-143829-3216@Xerox> From: Craig Partridge > I recall seeing a message on either tcp-ip or header-people a few > months back to the effect that the military timezones specified in RFC > 822 were wrong. I am now unable to find the message. A note to > header-people failed to shake it loose. Perhaps some kind soul on TCP-IP > could describe the problem to me again? From RFC 822: > Time zone may be indicated in several ways. "UT" is Univer- > sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- > mitted as a reference to Universal Time. The military standard > uses a single character for each zone. "Z" is Universal Time. > "A" indicates one hour earlier, and "M" indicates 12 hours ear- > lier; "N" is one hour later, and "Y" is 12 hours later. The > letter "J" is not used. The other remaining two forms are taken > from ANSI standard X3.51-1975. One allows explicit indication of > the amount of offset from UT; the other uses common 3-character > strings for indicating time zones in North America. This appears to be correct if we take "earlier" to mean east and "later" to mean west of GMT; I remember (from my time in the Navy) that time zone U is PST (-0800). However, just above, RFC 822 says: > zone = "UT" / "GMT" ; Universal Time > ; North American : UT > / "EST" / "EDT" ; Eastern: - 5/ - 4 > / "CST" / "CDT" ; Central: - 6/ - 5 > / "MST" / "MDT" ; Mountain: - 7/ - 6 > / "PST" / "PDT" ; Pacific: - 8/ - 7 > / 1ALPHA ; Military: Z = UT; > ; A:-1; (J not used) > ; M:-12; N:+1; Y:+12 > / ( ("+" / "-") 4DIGIT ) ; Local differential > ; hours+min. (HHMM) The sign of the on the lettered zones is just reversed of what it should be. Is this what you were looking for? Rich ----MESSAGE-END---- ----MESSAGE-BEGIN---- [CMM.0.86.580694943.hedrick@athos.rutgers.edu] <1988052700090300> From: hedrick@ATHOS.RUTGERS.EDU (Chuck Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: 802 (.2).3 TCP/IP Message-ID: Date: 27 May 88 00:09:03 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 I've just looked at RFC1042 again. While it is true that I have in the past tended to confuse 802.3 and 802.3, it's not clear that I did so in this message. In a paragraph at the end of the RFC, it uses language very similar to mine, referring to an 802.3 and an Ethernet link layer as separate standards. Since 802.3 includes wording saying that there is a length code rather than a type code, I generally consider that the term 802.3 is properly applied only to systems whose software actually do that. This is of course normally coupled with 802.2 as well. I did not mean to imply that 802.3 was used over token ring, etc. Obviously there are other 802.x standards for these other media. What I was trying to say was that in my view, RFC1042-style encapsulation will be used for all newer media, but that traditional 10MHz Ethernet implementations should continue to use the traditional encapsulation and not the one defined in RFC1042 (which while it may use the same basic ARP packets, presumes the use of 802.3 and in most cases 802.2, so that the headers put in front of the ARP packets would make it not interoperable with a system such as 4.3 BSD). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805280831.AA05285@ucbvax.Berkeley.EDU] <1988052701100000> From: miller@TWG.COM ("Miller, Grant") Newsgroups: comp.protocols.tcp-ip Subject: Mailing Lists Message-ID: <8805280831.AA05285@ucbvax.Berkeley.EDU> Date: 27 May 88 01:10:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 TCP-IP@sri-nic.arpa Please provide mailing list info at earliest convenience. miller@twg.com Grant Miller The Wollongong Group 1129 San Antonio Rd. Palo Alto, CA 94303 415-962-7207 If I have the wrong mail address please disregard. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [369@halley.UUCP] <1988052708483200> From: bc@halley.UUCP (Bill Crews) Newsgroups: comp.protocols.tcp-ip Subject: Re: Proteon's behaviour Message-ID: <369@halley.UUCP> Date: 27 May 88 08:48:32 GMT References: <880519-134446-6569@Xerox> <2773@umd5.umd.edu> <22924@bu-cs.BU.EDU> Reply-To: bc@halley.UUCP (Bill Crews) Organization: Tandem Computers, Austin, TX Lines: 32 In article <22924@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: >In article <2773@umd5.umd.edu> hans@umd5 (Hans Breitenlohner) writes: >>In article <880519-134446-6569@Xerox> Burrell.osbunorth@Xerox.COM, castillo.osbunorth@Xerox.COM writes: >>>It seems that the Proteon does some self testing of both of its Ethernet >>>interfaces and other internal hardware by sending small trash packets to itself >>>every so often through both interfaces. >>Two packets are sent out every 3.5 to 4 seconds. While this can be annoying >>in many respects, it is hard to see how this could consume much bandwidth. > If the router does not have a hardware interface test >capability, it's a pain when the interface doesn't work. Without a >test, it can't even detect a missing xcvr cable. I think you should >value the interface test. Software that generates timed transmissions, especially broadcasts, should have some facility for the interval to be tunable. In addition to Proteon's activity, I know Bridge network management has a 45-second "here I am" thing it does to keep net maps up to date. Keep-alives are popular topics of net conversation anyway, but tunable intervals seldom get much air time. I've certainly seen my share of networks with rwho disabled for this reason, too. In most cases, tuning would have to be coordinated netwide, although cases like the Proteon interface test would be easier to manage. When you add all these things together on a large LAN, you'd be amazed at the residual background activity. -bc -- Bill Crews bc@halley.UUCP (512) 244-8350 ..!rutgers!cs.utexas.edu!halley!bc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805270830.aa04122@CAD.USNA.MIL] <1988052712300300> From: tcs@USNA.MIL (Terry Slattery) Newsgroups: comp.protocols.tcp-ip Subject: Re: Need info on Ethernet products for the IBM AT and Sun Message-ID: <8805270830.aa04122@CAD.USNA.MIL> Date: 27 May 88 12:30:03 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 We also have the PC-NFS stuff and find that for FTP and TELNET we prefer to run the NCSA versions. They will work with the 3Com card along side the PC-NFS stuff. The combination solves many of the problems you mentioned with regard to ftp's mget and server mode, multiple telnet sessions, etc. I've also asked the Sun east coast division folks who are developing the PC-NFS product to look at the NCSA stuff (they have it) as a design goal for the next release. -tcs ps. PC-NFS supports the WD card now and the next NCSA version will have support for it (reportedly due out this summer). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [88@mace.cc.purdue.edu] <1988052713495900> From: abe@mace.cc.purdue.edu (Vic Abell) Newsgroups: comp.protocols.tcp-ip Subject: Re: subnetting supported by Sequents? Summary: Don't yell at Sequent; be polite. Message-ID: <88@mace.cc.purdue.edu> Date: 27 May 88 13:49:59 GMT References: <8805261504.AA27649@beno.CSS.GOV> Organization: Purdue University Lines: 17 In article <8805261504.AA27649@beno.CSS.GOV>, rick@SEISMO.CSS.GOV (Rick Adams) writes: > If you bitch and scream loudly enough, Sequent will send you a > special version of TCP. . . . > It is important to keep yelling at Sequent until they fix it. They > think that their customers don't care about things like > high performance networking. If enough sites keep complaining, they > might finally fix things. > > --rick This is completely different from our experience with Sequent. They do care, they do respond -- to polite and informed requests. Vic Abell ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805271400.AA05136@beast.DDN.MIL] <1988052714004000> From: stjohns@BEAST.DDN.MIL (Mike St. Johns) Newsgroups: comp.protocols.tcp-ip Subject: timezones in 822 Message-ID: <8805271400.AA05136@beast.DDN.MIL> Date: 27 May 88 14:00:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 1 In practice, I've never seen anything except time zone Z "ZULU" used by the military. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805271529.AA21200@sneezy] <1988052715292200> From: cpw%sneezy@LANL.GOV (C. Philip Wood) Newsgroups: comp.protocols.tcp-ip Subject: Re: PING with source/record route Message-ID: <8805271529.AA21200@sneezy> Date: 27 May 88 15:29:22 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 I posted a message about a modified 4.3 PING. The sources, and minimal information about, are on lambda.lanl.gov. FOR THOSE OF YOU OUT THERE WHO DO NOT RUN THE NAME SERVER: 128.165.4.16 phil wood ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805271205.aa03455@SPARK.BRL.ARPA] <1988052716052200> From: merritt@BRL.ARPA (Don Merritt) Newsgroups: comp.protocols.tcp-ip Subject: Re: PING with source/record route Message-ID: <8805271205.aa03455@SPARK.BRL.ARPA> Date: 27 May 88 16:05:22 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 The BRL ping program was modified by Phil Dykstra to handle the record route option a couple of months ago. It is available for anonymous ftp from host brl-vgr.arpa as ~ftp/pub/ping.tar. Here is Phil's description of the changes he made: The new ping differs by: 1) It will only show ICMP error messages when the -v flag is given. This will help reduce confusion from general users. 2) When IP packet headers are returned in ICMP error messages their headers are dumped broken down by fields. 3) Identification of ICMP error subcodes is now in the printed messages. 4) The RECORD_ROUTE option can be included in outgoing packets and the returned route is dumped. 5) Hostnames for dotted quads are looked up (unless a -n is given). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2799@ut-emx.UUCP] <1988052717162200> From: dlnash@ut-emx.UUCP (Donald L. Nash) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet packet type information requested. Message-ID: <2799@ut-emx.UUCP> Date: 27 May 88 17:16:22 GMT References: <8805231149.AA22588@msr.epm.ornl.gov> Organization: The University of Texas at Austin, Austin, Texas Lines: 41 Posted: Fri May 27 12:16:22 1988 In article <8805231149.AA22588@msr.epm.ornl.gov>, dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522) writes a very informative article which I would like to add to slightly. > Current BBN Ethernet and IEEE802.3 "Type" Fields > > 809B AppleTalk over Ethernet (Kinetics only?) I believe that this type number has been registered and is "official", whatever that may mean. Anyway, Apple uses it as well in their EtherTalk product. > Ethernet Vendor Addresses > > 080020 Sun Sun machines > 08002B DEC UNIBUS or QBUS machines, VAXen, LANBridges > (DEUNA, DEQNA, DELUA) The Texas Instruments Explorer (a Lisp workstation) has a vendor address of: 080028 TI TI Explorer Just thought I'd through in my $0.02 worth, if it is worth even that much.... Don Nash UUCP: ...!{ihnp4, allegra, seismo!ut-sally}!ut-emx!dlnash ARPA: dlnash@emx.utexas.edu BITNET: DLNASH@UTADNX, D.NASH@UTCHPC THENET: UTADNX::DLNASH, UTCHPC::D.NASH UUU UUU U U The University of Texas at Austin U TTTTUTTTTTTTTT Computation Center U T U TT T U U TT "The world is basically non-linear." UUUUUUU TT TT TTTT ----MESSAGE-END---- ----MESSAGE-BEGIN---- [925@actnyc.UUCP] <1988052719175300> From: gcf@actnyc.UUCP (Gordon Fitch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Third TCP-IP Book? Message-ID: <925@actnyc.UUCP> Date: 27 May 88 19:17:53 GMT References: <8805170601.AA21125@Larry.McRCIM.McGill.EDU> <12399598897.40.LYNCH@A.ISI.EDU> Reply-To: gcf@actnyc.UUCP (Gordon Fitch) Organization: InterACT Corporation Lines: 5 I'd like to get the full titles, etc., of the books that were mentioned. Unfortunately the original articles have expired here and I've only been able to read some of the follow-ups. -- Gordon Fitch (...!uunet!actnyc!gcf) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052720024700> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sat, 28 May 88 01:04:30 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA25819; Fri, 27 May 88 14:43:58 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 May 88 20:02:47 GMT From: kwe@bu-cs.bu.edu (kwe@bu-it.bu.edu (Kent W. England)) Organization: Boston Univ. Information Tech. Dept. Subject: Re: Getting started Message-Id: <22970@bu-cs.BU.EDU> References: <192@execu.EXECU> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <192@execu.EXECU> dewey@execu.EXECU (dewey henize) writes: >Ok, I'm obviously the slow one here, but... For some of us, this world of >TCP/IP and networking is a bit tough to pick up. I didn't have a chance >to learn about it in college so its been strictly OJT. Would anyone else >out there who has been in this position be willing to send or post a good >solid intro to mid level reading list? > I just put together a reading list for a brand new employee, a CS major with little experience with networking and TCP/IP. See what you think of this: o a campus network map annotated with IP and DECnet node numbers [learn by example] o Hedrick, "Introduction to the Internet Protocols" a tutorial that Charles Hedrick posted some time back and has published internally at Rutgers as an intro. Maybe substitute the Davidson or Comer book(s), if more readily available. o RFC1009, "Requirements for Internet Gateways" o Mockapetris, "Domain Names- Concepts and Facilities" latest RFC o IDEA0004, Hedrick, "RIP" essential for understanding routed and any distance vector routing protocol o man pages, Fedor, "Gated" soon to be published, maybe an IDEA, ... firewalling and access control o cisco, "Gateway Reference Manual" brand new with lots of intro material o Bosack and Hedrick, "Problems in Large LANs", IEEE Networks, Jan 88, all about synchronization and storms, etc o Stallings, "Handbook of Computer- Communications Standards" all three Vols: Vol 1 ISO Reference Model [old] Vol 2 IEEE standards [get that IEEE jargon down pat] Vol 3 TCP/IP protocol family [not sure how good this is] o RFCs: 791= IP 792= ICMP 793= TCP 891= Hello [I put this in for completeness on routing] 985, et al= EGP [maybe you should skip this] IDEA9= new EGP [there is hope] 950= subnetting 826= ARP 1027= proxy ARP 903= RARP 919/922=broadcasting 988= multicast [premature?] 894/825=IP on Enet encapsulation I guess this is heavily weighted toward routing, since that is our area of concern. There is certainly a lot to read. Track the IETF IDEAs and ineng-interest for all the latest stuff on routing exchange protocol improvements coming. Perhaps someone else has a list weighted to the applications (telnet, ftp, smtp, etc) or something better I missed? Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [210001@hpcsla.HP.COM] <1988052722385000> From: bdale@hpcsla.HP.COM (Bdale Garbee) Newsgroups: comp.protocols.tcp-ip Subject: Re: Proxy ARP (was Re: Dumb vs. smart host routing) Message-ID: <210001@hpcsla.HP.COM> Date: 27 May 88 22:38:50 GMT References: <882@kaos.UUCP> Organization: HP Colorado Springs Division Lines: 27 / srg@quick.COM (Spencer Garrett) / 2:15 am May 18, 1988 / >Why can't a host just ARP for any destination and expect the >appropriate gateway(s) to answer? If there were a hopcount >field in the ARP record, I think this would solve all the problems. We (N3CVL, K3MC, and myself) looked very hard about a year ago at doing something like this in the KA9Q Internet Package, to improve the situation on amateur packet radio, where almost noone can talk directly to anyone else, and so gateway/switch issues become very important. I eventually backed away from this idea when it became more clear to me that a distinction can and perhaps should be maintained between "routing" which is a logical operation, and "address resolution" which is (to me at least) a purely physical operation. However, my recent experience in designing and maintaining a sitewide LAN at work, including a bunch of discless clusters that for reasons of performance and cost will be subnetted by putting two ports on each discless server, have led me to be very interested in Proxy ARP, and other "ARP extensions". (If only HP would officially support Proxy ARP in HP-UX... sigh) My curiosity is up, therefore I also would be interested in comments on this subject. Bdale, N3EUA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805280116.aa28043@Huey.UDEL.EDU] <1988052805163800> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: timezones in 822 Message-ID: <8805280116.aa28043@Huey.UDEL.EDU> Date: 28 May 88 05:16:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Mike, Yup, "Z" is used by aviation, maritime and weather radio and wire as well. Actually, I'm bent much less by what you call it than by where the Sun is when you holler "lunchtime!" To be really picky, the real standard time told by the fuzzballs is UT-0 (corrected for mean solar rotation in steps of one second). It is possible to correct this time to 100-ms steps by listening to the radio broadcasts more carefully (these corrections are included in the broadcasts as vernier adjustments). If there is a huge groundswell of anguish that these adjustments are not included in the existing primary time server chimes, I would be glad to reconsider the issue. Then you could navigate your yachts by NTP down to the second or so in longitude. Happy day. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805280137.aa28106@Huey.UDEL.EDU] <1988052805373000> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: timezones in 822 Message-ID: <8805280137.aa28106@Huey.UDEL.EDU> Date: 28 May 88 05:37:30 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Rich, Aha! Another greasemonkey! The International Telecommunication Union (UIT), of which the CCITT and CCIR are parts, recommends the use of "J" to mean "daylight hours" and "N" to mean "nightime hours" and "X" to mean both, which should add another zest of grease to this discussion. We should point out that ISO has already standardized the time representation, of course. Now, let's talk about Antartica... Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988052808114600> Received: from Sun.COM by SRI-NIC.ARPA with TCP; Sat, 28 May 88 15:18:44 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA01527; Sat, 28 May 88 15:15:01 PDT Received: from sluggo.sun.com by snail.sun.com (4.0/SMI-3.2) id AA16819; Sat, 28 May 88 15:12:16 PDT Received: by sluggo.sun.com (4.0/SMI-4.0) id AA02054; Sat, 28 May 88 15:11:46 PDT Date: Sat, 28 May 88 15:11:46 PDT From: melohn@Sun.COM (Bill Melohn) Message-Id: <8805282211.AA02054@sluggo.sun.com> Newsgroups: comp.protocols.misc,comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Linking LAN's via Public X.25 References: <13652@comp.vuw.ac.nz> Reply-To: melohn@Sun.COM (Bill Melohn) Organization: Sun Microsystems, Mountain View Apparently-To: tcp-ip@sri-nic.ARPA In article <13652@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes: >From what I can tell SunLink X.25 does allow carrying IP packets from one lan >to another via an x.25 virtual circuit. What I would like to know is how >transparent this is. Does one host on the local ip lan (not necessarily the >Sun running SunLink x.25) just ask to send an ip packet to a node on the >remote lan, causing SunLink X.25 to open a VC to transmit the packet? The X.25 virtual circuit is treated exactly the same as a dedicated serial line connecting two IP hosts together. Routing information about networks on either side of the link is passed across the link via the standard Unix RIP. In the resulting internet, any host can access any other host using whatever IP based services are desired (note, protocols like NFS require some mount parameter tweaking in order to not timeout over slower, long haul links). >Assuming this is the way it works, does SunLink multiplex datagrams from >several tcp or udp sources over the one VC, and if so, at what point does it >close the VC? Are the local and remote lans on different class C ip networks >(I guess they must be to allow packets to be routed to the host with >the x.25)? How are the ip addresses mapped into x.121 addresses? >Finally from an economic point of view how reasonable is it to send ip >over x.25 bearing in mind the relatively large tcp + ip headers, >particularly when you are paying for both connect time and number of >segments sent (a segment is 64 octets, and NZ telcoms charge for >unfilled segments as one full one). As explained above, each VC is treated like a virtual point to point wire connecting each pair of hosts via the public data network. Each VC used for IP has a network interface associated with it, with an IP address of its own. An X.25 circuit manager user process is provided, which establishes the X.25 virtual circuits to each of the remote hosts based on a config file, and binds the VCs to the IP network interfaces used by the kernel routing code. The manager attempts to keep the VCs connected all the time. This can be expensive if you are paying for connect time, but since processes like the routing daemon tend to wake up and send information on a regular basis, the IP circuits tend to stay active even when they aren't actively being used for user data transfer. We are investigating ways to make it practical to create X.25 virtual circuits only when needed for end-user data transfer, while still maintaining full routing capabilities and connectivity information. Our implementation of X.25 Standard services does this on the DDN, where the X.121 to IP address mapping is fixed, and where routing can be done by use of a default route to, and redirects from, a core gateway. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [54821@sun.uucp] <1988052822175500> From: melohn%sluggo@Sun.COM (Bill Melohn) Newsgroups: comp.protocols.misc,comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Linking LAN's via Public X.25 Message-ID: <54821@sun.uucp> Date: 28 May 88 22:17:55 GMT References: <13652@comp.vuw.ac.nz> Sender: news@sun.uucp Reply-To: melohn@sun.UUCP (Bill Melohn) Organization: Sun Microsystems, Mountain View Lines: 45 In article <13652@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes: >From what I can tell SunLink X.25 does allow carrying IP packets from one lan >to another via an x.25 virtual circuit. What I would like to know is how >transparent this is. Does one host on the local ip lan (not necessarily the >Sun running SunLink x.25) just ask to send an ip packet to a node on the >remote lan, causing SunLink X.25 to open a VC to transmit the packet? The X.25 virtual circuit is treated exactly the same as a dedicated serial line connecting two IP hosts together. Routing information about networks on either side of the link is passed across the link via the standard Unix RIP. In the resulting internet, any host can access any other host using whatever IP based services are desired (note, protocols like NFS require some mount parameter tweaking in order to not timeout over slower, long haul links). >Assuming this is the way it works, does SunLink multiplex datagrams from >several tcp or udp sources over the one VC, and if so, at what point does it >close the VC? Are the local and remote lans on different class C ip networks >(I guess they must be to allow packets to be routed to the host with >the x.25)? How are the ip addresses mapped into x.121 addresses? >Finally from an economic point of view how reasonable is it to send ip >over x.25 bearing in mind the relatively large tcp + ip headers, >particularly when you are paying for both connect time and number of >segments sent (a segment is 64 octets, and NZ telcoms charge for >unfilled segments as one full one). As explained above, each VC is treated like a virtual point to point wire connecting each pair of hosts via the public data network. Each VC used for IP has a network interface associated with it, with an IP address of its own. An X.25 circuit manager user process is provided, which establishes the X.25 virtual circuits to each of the remote hosts based on a config file, and binds the VCs to the IP network interfaces used by the kernel routing code. The manager attempts to keep the VCs connected all the time. This can be expensive if you are paying for connect time, but since processes like the routing daemon tend to wake up and send information on a regular basis, the IP circuits tend to stay active even when they aren't actively being used for user data transfer. We are investigating ways to make it practical to create X.25 virtual circuits only when needed for end-user data transfer, while still maintaining full routing capabilities and connectivity information. Our implementation of X.25 Standard services does this on the DDN, where the X.121 to IP address mapping is fixed, and where routing can be done by use of a default route to, and redirects from, a core gateway. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [50244@ti-csl.CSNET] <1988052902530100> From: pf@csc.ti.com (Paul Fuqua) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet packet type information requested. Message-ID: <50244@ti-csl.CSNET> Date: 29 May 88 02:53:01 GMT References: <2799@ut-emx.UUCP> Sender: root@ti-csl.CSNET Organization: TI Computer Science Center Lines: 21 Posted: Sat May 28 21:53:01 1988 Date: Friday, May 27, 1988 12:16pm (CDT) From: dlnash at ut-emx.UUCP (Donald L. Nash) Subject: Re: Ethernet packet type information requested. Newsgroups: comp.protocols.tcp-ip The Texas Instruments Explorer (a Lisp workstation) has a vendor address of: 080028 TI TI Explorer After asking around, I believe that the vendor address also applies to Ethernet boards in TI Business System xxxx's (Sys V Unix boxes); I don't know if we make any other Ethernettable hardware. pf Paul Fuqua Texas Instruments Computer Science Center, Dallas, Texas CSNet: pf@csc.ti.com (ARPA too, eventually) UUCP: {smu, texsun, im4u, rice}!ti-csl!pf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [580881809.0.OLE@CSLI.Stanford.EDU] <1988052904032900> From: OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen) Newsgroups: comp.protocols.tcp-ip Subject: Re: 3rd TCP-IP book Message-ID: <580881809.0.OLE@CSLI.Stanford.EDU> Date: 29 May 88 04:03:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 I spoke with one of the authors, Don Huntington, the other day. The project has been cancelled and "The Complete Guide to TCP/IP" will not see the presses after all. So we've got Stallings, Davidson and Comer for now. Ole ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3325@phri.UUCP] <1988052915121800> From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.unix.wizards,comp.protocols.tcp-ip Subject: How is OOB data supposed to work? Message-ID: <3325@phri.UUCP> Date: 29 May 88 15:12:18 GMT Organization: Public Health Research Institute, NYC, NY Lines: 44 I'm having a bit of trouble figuring out how out-of-band data works with stream sockets (i.e. TCP connections) in BSD Unix (I'm using a MtXinu 4.3BSD/NFS vax and a SunOS-3.2 Sun-3). Hopefully some of you network wizards out there can set me straight. My server side looks basicly like: sock = socket (AF_INET, SOCK_STREAM, 0); bind (sock, &server, sizeof (server)); listen (sock, 5); msgsock = accept (sock, 0, 0); while (1) { rfd = efd = 1< From: budden@tetra.NOSC.MIL (Rex A. Buddenberg) Newsgroups: comp.protocols.tcp-ip Subject: Re: timezones in 822 Message-ID: <686@tetra.NOSC.MIL> Date: 29 May 88 23:44:04 GMT References: <8805280137.aa28106@Huey.UDEL.EDU> Reply-To: budden@tetra.nosc.mil.UUCP (Rex A. Buddenberg) Organization: Naval Ocean Systems Center, San Diego Lines: 18 "Now lets talk about Antarctica..." Time there gets interesting, simply because you can cross so many zones in a small linear distance... but the interesting problem is this: When you are at the Pole, every direction is north, or 000 (recall the color-of-the-bear riddle about the other Pole). So how do you fly out? If you pick any of the 'norths' at random, all but one of them lead somewhere other than McMurdo -- and not places you want to go. The conventional fix to the problem is to superimpose a grid over the true geography -- graft a piece of the equator over the pole, so to speak. Grid north is generally aligned along the Prime Meridian, so grid south runs along 180, grid east up the 090 meridian, etc. Rex Buddenberg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5673@umn-cs.cs.umn.edu] <1988053000350400> From: amit@umn-cs.cs.umn.edu (Neta Amit) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc Subject: U of MN NetBIOS Gateway to Internet Message-ID: <5673@umn-cs.cs.umn.edu> Date: 30 May 88 00:35:04 GMT Reply-To: amit@umn-cs.UUCP (Neta Amit) Organization: University of Minnesota Lines: 49 Posted: Sun May 29 19:35:04 1988 We are running a PC-LAN of some 20 nodes, with a gateway to the main departmental Ethernet. A dedicated AT with 3C501 card serves as a gateway and mail server (no, we don't use POP), as well as file server and print server for the IBM PC Network it's running. The Gateway software has been developed locally, and our ip/tcp is derived from MIT's and CMU's pc/ip. Mail was first installed over a year ago, Telnet is a few months old, FTP is in development. The machines are fairly loaded, but the load on the gateway is light. The gateway does as little a processing as possible, e.g. incoming packets are sent immediately to their destination, where they are assembled. As a result, the gateway's capacity is much better than that reported in similar projects. Last night we did a little experiemnt which might be of some interest to this newsgroup. We tried to overload the gateway, by connecting 14 nodes to it. Two nodes sent mail messages consisting of the file /etc/hosts (.25MB). The other 12 were logged in remotely, mostly to local machines, cat'ing /etc/hosts one by one, in a staggerring fashion. When we turned the debugging mechanism on to trace packets at the gateway, we noticed that remote sessions were running at a reasonable speed, where as Mail was flowing very slowly. When the 10th node started to cat, the gateway choked and died, due to a previously undetected bug. In part, this was due packet buffer being full. The buffer's capacity is 20 packets: 4 are permanently assigned to Mail, 2 in 2 out; another 2 are also dedicated; 14 are for telnet/ftp. The software is executing in the Small memory model, close to the limit, hence expansion of the buffer is not very likely. We then invoked a second gateway. We have the capability to statically assign different nodes to different gateways on the same subnet, with no overlapping. The second gateway is a standard AT node, NOT a file and print server of the PC-LAN. Reconfiguration requires rebooting. The improvement was instantaneous. Mail began to flow 8 times faster. Gateway buffers were only half-full. No problem has been noticed. --Neta Amit (amit@umn-cs.cs.umn.edu) University of Minnesota CSci -- Neta Amit U of Minnesota CSci Arpanet: amit@umn-cs.cs.umn.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988053005541000> Received: from zaphod.ncsa.uiuc.edu by SRI-NIC.ARPA with TCP; Mon, 30 May 88 08:59:20 PDT Return-Path: Received: by zaphod.ncsa.uiuc.edu (4.0/NCSA-1.2) id AA19718; Mon, 30 May 88 10:54:10 CDT Date: Mon, 30 May 88 10:54:10 CDT From: timk@ncsa.uiuc.edu (Tim Krauskopf) Message-Id: <8805301554.AA19718@zaphod.ncsa.uiuc.edu> X-Mailer: Mail User's Shell (Vers 6.0) Sat Apr 2 19:36:07 PST 1988 To: cire@clash.cisco.com Subject: Re: Need info on Ethernet products for the IBM AT and Sun Cc: tcp-ip@sri-nic.arpa >To: amdcad!phil@ucbvax.berkeley.edu (Phil Ngai) >Cc: tcp-ip@sri-nic.arpa, cire@clash.cisco.com >Subject: Re: Need info on Ethernet products for the IBM AT and Sun >Date: Tue, 24 May 88 16:47:22 PDT >From: cire@clash.cisco.com >> Date: 19 May 88 18:47:53 GMT >> From: amdcad!phil@ucbvax.Berkeley.EDU (Phil Ngai) >> Organization: Advanced Micro Devices >> Subject: Re: Need info on Ethernet products for the IBM AT and Sun >> References: <5503@potomac.ads.com> >> Sender: tcp-ip-request@sri-nic.arpa >> To: tcp-ip@sri-nic.arpa >> .... ..... >> >> 3) ftp client blows up on mget with a small number of files, says >> "Arguments too long". >> 4) ftp client dies if you go back to telnet too long. >A lot of the problems you have mentioned above but in particular 3 and >4 are a direct result of PC-NFS being built on top of MS-DOG! The >FTP clint is trying to do an expansion locally but the local command >parser is severally brain-dead so it pukes. The FTP client dies when >you go to telnet too long because of the single threaded nature of th >box. >Eric B. Decker >cisco Systems >Menlo Park, California Nothing is impossible . . . Our design for NCSA Telnet supports multiple telnet sessions and FTP in the background simultaneously under MS-DOS. Same thing for MacOS and both OS's are "single-threaded". You just have to wrap the thread real fast. Tim Krauskopf timk@ncsa.uiuc.edu (ARPA) National Center for Supercomputing Applications (NCSA) University of Illinois, Urbana-Champaign ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988053010130000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Tue, 31 May 88 03:12:33 PDT Date: 30 May 1988 14:13-EDT Sender: URBANIAK@G.BBN.COM Subject: Ethernet Type Fields and Addresses From: URBANIAK@G.BBN.COM To: tcp-ip@SRI-NIC.ARPA, big-lan@SUVM.ACS.SYR.EDU Cc: Urbaniak@G.BBN.COM Message-ID: <[G.BBN.COM]30-May-88 14:13:58.URBANIAK> Below are the current lists of values known at BBN for: Ethernet Type Fields; Ethernet Address Vendor assignments; Ethernet Multicast Address assignments. As these values are not published by the IEEE, we maintain these lists for our use, and for distribution. Please send corrections and updates directly to me at Urbaniak@BBN.COM. Current Ethernet and IEEE802.3 "Type" Fields 5/5/88 The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble) consist of the "Type" or "Length" field. These are formerly assigned by Xerox, currently assigned by IEEE. Some assignments are public, others private. Information currently available includes: Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std, but not yet further documentation from IEEE; NIC RFC960; knowledge of some BBN Private Type Field values. Hex 0000-05EE IEEE802.3 Length Field 0600 Xerox NS IDP * 0800 DOD Internet Protocol (IP) * # 0801 X.75 Internet 0802 NBS Internet 0803 ECMA Internet 0804 CHAOSnet 0805 X.25 Level 3 0806 Address Resolution Protocol (ARP) * (for IP and for CHAOS) 0807 XNS Compatibility 081C Symbolics Private 1000 Berkeley Trailer negotiation 1001-100F Berkeley Trailer encapsulation 1600 VALID-machine protocol? * 5208 BBN Simnet Private % 6000 DEC unassigned 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 6003 DECNET Phase IV 6004 DEC Local Area Transport (LAT) 6005 DEC diagnostic protocol (at interface initialization?) 6006 DEC customer protocol 6007 DEC Local Area VAX Cluster (LAVC) 6008 DEC unassigned 6009 DEC unassigned 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe protocol 8006 Nestar 8010 Excelan 8035 Reverse Address Resolution Protocol (RARP) 8038 DEC LanBridge Management 8039 DEC unassigned 803A DEC unassigned 803B DEC unassigned 803C DEC unassigned 803D DEC Ethernet Encryption Protocol 803E DEC unassigned 803F DEC LAN Traffic Monitor Protocol 8040 DEC unassigned 8041 DEC unassigned 8042 DEC unassigned 805B Stanford V Kernel, experimental 805C Stanford V Kernel, production 809B EtherTalk (AppleTalk over Ethernet) 80F3 AppleTalk Address Resolution Protocol (AARP) 9000 Loopback (Configuration Test Protocol) FF00 BBN VITAL-LanBridge cache wakeups % * These protocols use Ethernet broadcast, where multicast would be preferable. # BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3. % BBN Private Protocols, not registered Ethernet Vendor Addresses 4/29/88 Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits (0-9, plus A-F, capitalized). These 12 hex digits consist of the first/left 6 digits (which should match the vendor of the Ethernet interface within the station) and the last/right 6 digits which specify the interface serial number for that interface vendor. Currently we have noted the following vendor addresses, on the BBN Corporate Ethernet. 000093 Proteon 0000AA Xerox Xerox machines 000102 BBN BBN internal usage (not registered) 00DD00 Ungermann-Bass 020701 Interlan UNIBUS or QBUS machines 020406 BBN BBN internal usage (not registered) 02608C 3Com IBM PC; Imagen; Valid 02CF1F CMC Masscomp 080002 Bridge 080005 Symbolics Symbolics LISP machines 080009 Hewlett-Packard 080010 AT+T 080014 Excelan BBN Butterfly, Masscomp 08001A Data General 08001E Apollo 080020 Sun Sun machines 080028 TI Explorer 08002B DEC UNIBUS or QBUS machines, VAXen, LANBridges (DEUNA, DEQNA, DELUA) 080047 Sequent 08004C Encore 080068 Ridge 080089 Kinetics AppleTalk-Ethernet interface 08008B Pyramid 08008D XyVision XyVision machines AA0003 DEC Physical address for some DEC machines AA0004 DEC Logical address for systems running DECNET Ethernet addresses might be written unhyphenated (e.g. 123456789ABC), or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated by octets (e.g. 12-34-56-78-9A-BC). These addresses are physical station addresses, not multicast nor broadcast, so the second hex digit (reading from the left) will be even, not odd. At present, it is not clear how the IEEE assigns Ethernet block addresses. Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned with that block or separately. A portion of the vendor block address is reportedly assigned serially, with the other portion intentionally assigned randomly. If there is a global algorithm for which addresses are designated to be physical (in a chipset) versus logical (assigned in software), I am unaware of the algorithm. Current Ethernet Multicast Addresses 5/5/88 Ethernet Type Address Field Usage Multicast Addresses: 09-00-2B-01-00-01 8038 DEC LanBridge Hello packets 1 packet per second, sent by the designated LanBridge AB-00-00-01-00-00 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance AB-00-00-02-00-00 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 1 System ID packet every 8-10 minutes, by every: DEC LanBridge DEC DEUNA interface DEC DELUA interface DEC DEQNA interface (in a certain mode) AB-00-00-03-00-00 6003 DECNET Phase IV end node Hello packets 1 packet every 15 seconds, sent by each DECNET host AB-00-00-04-00-00 6003 DECNET Phase IV Router Hello packets 1 packet every 15 seconds, sent by the DECNET router AB-00-00-05-00-00 ???? Reserved DEC through AB-00-03-FF-FF-FF AB-00-04-00-00-00 ???? Reserved DEC customer private use through AB-00-04-FF-FF-FF AB-00-04-01-xx-yy 6007 DEC Local Area VAX Cluster (LAVC Cluster group yy) CF-00-00-00-00-00 9000 Ethernet Configuration Test protocol (Loopback) Broadcast Address: FF-FF-FF-FF-FF-FF 0600 XNS packets, Hello or gateway search? 6 packets every 15 seconds, per XNS station FF-FF-FF-FF-FF-FF 0800 IP (e.g. RWHOD via UDP) as needed FF-FF-FF-FF-FF-FF 0806 ARP (for IP and CHAOS) as needed FF-FF-FF-FF-FF-FF 1600 VALID packets, Hello or gateway search? 1 packets every 30 seconds, per VALID station ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805301617.AA12643@ucbvax.Berkeley.EDU] <1988053014450300> From: jon@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Network Management Message-ID: <8805301617.AA12643@ucbvax.Berkeley.EDU> Date: 30 May 88 14:45:03 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 49 A couple of weeks ago i sent a message to this list asking about management tools for TCP/IP type networks. One ground rule was the public availability of said tools (i.e. exclude expensive things, but include things at least binary avail like tcpdump). The categories for tools of interest were: configuration e.g. gated/rip/egp/routed - routes bind - names rdist - info distrib. info-servers - distr. info db - ucl distr. account management thorn ds - a nearly real X.500 (but over TCP as well as OSI) directory service fault finding/performance ping - liveness/reachability/errors ttcp - udp/tcp traffic gen. etherfind/tcpdump - protocol behaviour - intruder detection... statistics NSStat - overall net stats probe - ucl icmp based reachability prog. flakeway - ucl PC based fake arpanet map - UCL traffic analyser helps decide where to partition your LAN So far i've had 6 replies saying "gosh that would be a very useful list of info. to collate" and 0 replies saying, "heres a really neat program for doing everything and it runs on anything bigger than a pocket calculator, speaks LAT, X.25, can parse ASN.1 and pretty print an X.400 header. it also makes excuses for..." can anyone help... jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988053017250300> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Mon, 30 May 88 07:49:42 PDT Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK via Ethernet with SMTP id aa02904; 30 May 88 15:42 BST To: tcp-ip@sri-nic.arpa Subject: Network Management Date: Mon, 30 May 88 15:45:03 +0100 From: Jon Crowcroft A couple of weeks ago i sent a message to this list asking about management tools for TCP/IP type networks. One ground rule was the public availability of said tools (i.e. exclude expensive things, but include things at least binary avail like tcpdump). The categories for tools of interest were: configuration e.g. gated/rip/egp/routed - routes bind - names rdist - info distrib. info-servers - distr. info db - ucl distr. account management thorn ds - a nearly real X.500 (but over TCP as well as OSI) directory service fault finding/performance ping - liveness/reachability/errors ttcp - udp/tcp traffic gen. etherfind/tcpdump - protocol behaviour - intruder detection... statistics NSStat - overall net stats probe - ucl icmp based reachability prog. flakeway - ucl PC based fake arpanet map - UCL traffic analyser helps decide where to partition your LAN So far i've had 6 replies saying "gosh that would be a very useful list of info. to collate" and 0 replies saying, "heres a really neat program for doing everything and it runs on anything bigger than a pocket calculator, speaks LAT, X.25, can parse ASN.1 and pretty print an X.400 header. it also makes excuses for..." can anyone help... jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM]30-May-88.14:13:58.URBANIAK] <1988053018130000> From: URBANIAK@G.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Ethernet Type Fields and Addresses Message-ID: <[G.BBN.COM]30-May-88.14:13:58.URBANIAK> Date: 30 May 88 18:13:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 163 Below are the current lists of values known at BBN for: Ethernet Type Fields; Ethernet Address Vendor assignments; Ethernet Multicast Address assignments. As these values are not published by the IEEE, we maintain these lists for our use, and for distribution. Please send corrections and updates directly to me at Urbaniak@BBN.COM. Current Ethernet and IEEE802.3 "Type" Fields 5/5/88 The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble) consist of the "Type" or "Length" field. These are formerly assigned by Xerox, currently assigned by IEEE. Some assignments are public, others private. Information currently available includes: Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std, but not yet further documentation from IEEE; NIC RFC960; knowledge of some BBN Private Type Field values. Hex 0000-05EE IEEE802.3 Length Field 0600 Xerox NS IDP * 0800 DOD Internet Protocol (IP) * # 0801 X.75 Internet 0802 NBS Internet 0803 ECMA Internet 0804 CHAOSnet 0805 X.25 Level 3 0806 Address Resolution Protocol (ARP) * (for IP and for CHAOS) 0807 XNS Compatibility 081C Symbolics Private 1000 Berkeley Trailer negotiation 1001-100F Berkeley Trailer encapsulation 1600 VALID-machine protocol? * 5208 BBN Simnet Private % 6000 DEC unassigned 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 6003 DECNET Phase IV 6004 DEC Local Area Transport (LAT) 6005 DEC diagnostic protocol (at interface initialization?) 6006 DEC customer protocol 6007 DEC Local Area VAX Cluster (LAVC) 6008 DEC unassigned 6009 DEC unassigned 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe protocol 8006 Nestar 8010 Excelan 8035 Reverse Address Resolution Protocol (RARP) 8038 DEC LanBridge Management 8039 DEC unassigned 803A DEC unassigned 803B DEC unassigned 803C DEC unassigned 803D DEC Ethernet Encryption Protocol 803E DEC unassigned 803F DEC LAN Traffic Monitor Protocol 8040 DEC unassigned 8041 DEC unassigned 8042 DEC unassigned 805B Stanford V Kernel, experimental 805C Stanford V Kernel, production 809B EtherTalk (AppleTalk over Ethernet) 80F3 AppleTalk Address Resolution Protocol (AARP) 9000 Loopback (Configuration Test Protocol) FF00 BBN VITAL-LanBridge cache wakeups % * These protocols use Ethernet broadcast, where multicast would be preferable. # BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3. % BBN Private Protocols, not registered Ethernet Vendor Addresses 4/29/88 Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits (0-9, plus A-F, capitalized). These 12 hex digits consist of the first/left 6 digits (which should match the vendor of the Ethernet interface within the station) and the last/right 6 digits which specify the interface serial number for that interface vendor. Currently we have noted the following vendor addresses, on the BBN Corporate Ethernet. 000093 Proteon 0000AA Xerox Xerox machines 000102 BBN BBN internal usage (not registered) 00DD00 Ungermann-Bass 020701 Interlan UNIBUS or QBUS machines 020406 BBN BBN internal usage (not registered) 02608C 3Com IBM PC; Imagen; Valid 02CF1F CMC Masscomp 080002 Bridge 080005 Symbolics Symbolics LISP machines 080009 Hewlett-Packard 080010 AT+T 080014 Excelan BBN Butterfly, Masscomp 08001A Data General 08001E Apollo 080020 Sun Sun machines 080028 TI Explorer 08002B DEC UNIBUS or QBUS machines, VAXen, LANBridges (DEUNA, DEQNA, DELUA) 080047 Sequent 08004C Encore 080068 Ridge 080089 Kinetics AppleTalk-Ethernet interface 08008B Pyramid 08008D XyVision XyVision machines AA0003 DEC Physical address for some DEC machines AA0004 DEC Logical address for systems running DECNET Ethernet addresses might be written unhyphenated (e.g. 123456789ABC), or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated by octets (e.g. 12-34-56-78-9A-BC). These addresses are physical station addresses, not multicast nor broadcast, so the second hex digit (reading from the left) will be even, not odd. At present, it is not clear how the IEEE assigns Ethernet block addresses. Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned with that block or separately. A portion of the vendor block address is reportedly assigned serially, with the other portion intentionally assigned randomly. If there is a global algorithm for which addresses are designated to be physical (in a chipset) versus logical (assigned in software), I am unaware of the algorithm. Current Ethernet Multicast Addresses 5/5/88 Ethernet Type Address Field Usage Multicast Addresses: 09-00-2B-01-00-01 8038 DEC LanBridge Hello packets 1 packet per second, sent by the designated LanBridge AB-00-00-01-00-00 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance AB-00-00-02-00-00 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 1 System ID packet every 8-10 minutes, by every: DEC LanBridge DEC DEUNA interface DEC DELUA interface DEC DEQNA interface (in a certain mode) AB-00-00-03-00-00 6003 DECNET Phase IV end node Hello packets 1 packet every 15 seconds, sent by each DECNET host AB-00-00-04-00-00 6003 DECNET Phase IV Router Hello packets 1 packet every 15 seconds, sent by the DECNET router AB-00-00-05-00-00 ???? Reserved DEC through AB-00-03-FF-FF-FF AB-00-04-00-00-00 ???? Reserved DEC customer private use through AB-00-04-FF-FF-FF AB-00-04-01-xx-yy 6007 DEC Local Area VAX Cluster (LAVC Cluster group yy) CF-00-00-00-00-00 9000 Ethernet Configuration Test protocol (Loopback) Broadcast Address: FF-FF-FF-FF-FF-FF 0600 XNS packets, Hello or gateway search? 6 packets every 15 seconds, per XNS station FF-FF-FF-FF-FF-FF 0800 IP (e.g. RWHOD via UDP) as needed FF-FF-FF-FF-FF-FF 0806 ARP (for IP and CHAOS) as needed FF-FF-FF-FF-FF-FF 1600 VALID packets, Hello or gateway search? 1 packets every 30 seconds, per VALID station ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805301732.aa17843@Huey.UDEL.EDU] <1988053021322000> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: timezones in 822 Message-ID: <8805301732.aa17843@Huey.UDEL.EDU> Date: 30 May 88 21:32:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 Rex, Geeze, last I ran phone patches with the KC4 folk at the various US bases in Antarctica they were keeping Greenwich time but living US Eastern Time and working radio between 0300 UT and 0900 UT on whatever frequencies got through. Such hours resulted in some sleepy wives when I patched them through to their old man stuck at Palmer Station, which turns out to be, at 64 west longitude, pretty close to US Eastern Time). Now, I have two QSL cards from Navy Seebee batallions listing their coordinates as 0W, 90S, which suggests they salute Greenwich instead. Who cares when you'r humping theodolites with a SnoCat at 60 below. By the by, the boys there tell me about the 100-degree club, not so well known and sort of an initiation haze. The victim takes the 100-degree plus shower, then is thrown out the door in the 100-degree minus snowdrift. All temperatures are F and the victim is presumably rescued before his parts start falling off his nude bod. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12402531387.20.LYNCH@A.ISI.EDU] <1988053021394200> From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Getting started Message-ID: <12402531387.20.LYNCH@A.ISI.EDU> Date: 30 May 88 21:39:42 GMT References: <192@execu.EXECU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Dewey, Kent England has already responded with a good list of reading materials. I would add that the Comer book, "Internetworking with TCP/IP", published by Prentice Hall, ISBN 0-13-470154-2, price $36, is excellent material for the serious reader. It gives a lot of "motivational material" to understand why Internetting is both desirable and not exactly trivial. Chuck Hedrick's 25 page intro to TCP/IP and campus networking is also a handy starter. There are so many aspects to networking that is is hard to find the right materials for each person who is trying to get started. We try to fill some of the gaps with tutorials of all flavors (beginner, middle, advanced, and obscure) and find that people flock to them when they are offered publically. I hope that Universities will pick up on Comer's book and use it as a text book. WE need more people to understand how to design, build and operate internets. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805310051.AA09423@beno.CSS.GOV] <1988053100515800> From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: subnetting supported by Sequents? Message-ID: <8805310051.AA09423@beno.CSS.GOV> Date: 31 May 88 00:51:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 When I politely asked Sequent to provide better TCP support and SLIP support I was told "the customers dont want it, so we wont waste time providing it". When I bitched loudly and publically about it, I got a fixed TCP. Draw your own conclusions. --rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [714@lakesys.UUCP] <1988053104084700> From: mikep@lakesys.UUCP (Mike Pluta) Newsgroups: comp.protocols.tcp-ip Subject: non-*NIX implementations Message-ID: <714@lakesys.UUCP> Date: 31 May 88 04:08:47 GMT Reply-To: mikep@lakesys.UUCP (Mike Pluta) Organization: Lake Systems - Milwaukee, WI Lines: 8 Is anyone familiar with a NON-*NIX implementation of the TCP/IP protocols? -- Michael J Pluta (mikep@lakesys.UUCP) c/o | {ihnp4,uwvax}! Tri-Sys Computer Corp., Inc. | uwmcsd1!lakesys! 207 East Buffalo Street, Suite 600 | mikep Milwaukee, WI 53202 | ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988053106123300> Received: from omnigate.clarkson.edu (MILNET-GW.CLARKSON.EDU) by SRI-NIC.ARPA with TCP; Tue, 31 May 88 07:16:13 PDT Date: Tue, 31 May 88 10:12:33 EDT From: MESSAGE AGENT Subject: Re: Gateway to Net Ten To: TCP-IP@sri-nic.arpa This is an automatic reply. Feel free to send additional mail, as only this one notice will be generated. The following is a prerecorded message, sent for ahd 27 November 1987 I don't know what to say in this, my last note from Buffalo, New York. Good and bad things have happened to me since the end of October that defy description, and the only people who would believe me already have enough stories to tell about me without creating new legends. The people who made the good things happen know who they are, and as for the bad things... I prefer to lump them together as acts of God and leave it at that. However, the end result of those past four weeks is that I now have survived my first week working for AGS Information Services on site at IBM Kingston preparing to change software that I'm not allowed to discuss, I enjoy the work, and I expect it to last a while. I also have found an apartment in Kingston, and will be tearing down my computer to be moved there as soon as I log off. My new address as of 1 December 1987 is: Andrew H. Derbyshire 578 Broadway, Apt 6 Kingston, NY 12401 My telephone will be hooked up on 4 December, and the number will be: 914-339-7425 Note that use of either of these is better than sending me mail on omnigate, because now that I am working I intend on letting my online mail exchanges die a natural death and use real world communications instead. This advice applies to answering this letter, so please send me a holiday greeting at 578 Broadway instead of answering this online. Most of all though, don't be a stranger. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988053112150400> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Tue, 31 May 88 14:11:24 PDT Received: from OHSTVMA.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 8905; Tue, 31 May 88 16:19:33 EDT Received: by OHSTVMA (Mailer X1.25) id 9894; Tue, 31 May 88 16:18:31 EDT Date: Tue, 31 May 88 16:15:04 EDT From: TS1347%OHSTVMA.BITNET@CUNYVM.CUNY.EDU (Tim A Scott) To: tcp-ip@sri-nic.arpa Subject: BAYNESRT@v880np.NEWPORT Mr. Baynes address on the From: line is incorrect. Please send to: baynesrt%v880np.decnet@nusc-npt.arpa Tim Scott Postmaster at OSU ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805311243.AA16674@gatech.edu] <1988053112430300> From: ken@GATECH.EDU (Ken Seefried iii) Newsgroups: comp.protocols.tcp-ip Subject: Re: non-*NIX implimentations Message-ID: <8805311243.AA16674@gatech.edu> Date: 31 May 88 12:43:03 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 In respose to Micheal J Pluta (mikep@lakesys.uucp), i know of at least two non unix tcpip ports. Here at Ga Tech, we are running TCP/IP on 2 CDC Cyber 180 machines under NOS/VE and on an IBM 4381 under VM. I do not have the details availible, but if you drop me some e-mail, Ill be glad to dig them up... ken seefried iii ...!{akgua, allegra, amd, harpo, hplabs, ken@gatech.edu inhp4, masscomp, rlgvax, sb1, uf-cgrl, ccastks@gitvm1.bitnet unmvax, ut-ngp, ut-sally}!gatech!ken soon to be open: ...!gatech!spooge!ken (finally ;'}) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19880531124503.7.HORNIG@WINTER.SCRC.Symbolics.COM] <1988053112450000> From: Hornig@ALDERAAN.SCRC.SYMBOLICS.COM (Charles Hornig) Newsgroups: comp.protocols.tcp-ip Subject: Ethernet Type Fields and Addresses Message-ID: <19880531124503.7.HORNIG@WINTER.SCRC.Symbolics.COM> Date: 31 May 88 12:45:00 GMT References: <[G.BBN.COM]30-May-88.14:13:58.URBANIAK> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 2 For those collecting such information, Ethernet type codes 8107, 8108, and 8109 are assigned to Symbolics, Inc. for internal use. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [528@xios.XIOS.UUCP] <1988053113201400> From: peter@xios.XIOS.UUCP (Peter Manson) Newsgroups: comp.protocols.tcp-ip Subject: Re: PING with source/record route Message-ID: <528@xios.XIOS.UUCP> Date: 31 May 88 13:20:14 GMT Article-I.D.: xios.528 Posted: Tue May 31 09:20:14 1988 Reply-To: peter@xios.UUCP (Peter Manson) Organization: XIOS Systems Corporation, Ottawa, Ontario, Canada Lines: 35 Thanks very much to everyone who replied to my question about PING. Here's my interpretation of the various replies: PING (Packet Inter-Net Groper) was originally written in PDP-11 assembler for the fuzzball around 1980. Mike Muuss is the author of the UNIX version. Phil Dykstra at BRL modified it as follows (Mike Minnich (minnich@udel.edu) apparently also did some modifications including record route): 1) It will only show ICMP error messages when the -v flag is given. This will help reduce confusion from general users. 2) When IP packet headers are returned in ICMP error messages their headers are dumped broken down by fields. 3) Identification of ICMP error subcodes is now in the printed messages. 4) The RECORD_ROUTE option can be included in outgoing packets and the returned route is dumped. 5) Hostnames for dotted quads are looked up (unless a -n is given). The BRL version can be obtained by public FTP from brl-vgr.arpa (also known as vgr.brl.mil) in the file ~ftp/pub/ping.tar. In addition, Phil Wood (the poster of the original message a while ago) says there are sources on lambda.lanl.gov (128.165.4.16). I don't know which version this is. (I haven't checked these FTP-able sources, since I'm not on the Internet.) ---------------------------------------------------------------------------- Peter Manson | XIOS Systems Corp. | 150-1600 Carling Avenue, | peter@xios.uucp from UUCP Ottawa, Ontario | xios.uucp!peter@uunet.uu.net from Internet K1Z 8R8 | CANADA | (613) 725-5411 | ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988053113520000> Received: from CORNELLC.CCS.CORNELL.EDU by SRI-NIC.ARPA with TCP; Tue, 31 May 88 15:54:59 PDT Received: from SSCvax.McMaster.CA by CORNELLC.CCS.CORNELL.EDU ; Tue, 31 May 88 18:50:49 EDT Date: Tue, 31 May 88 18:52 EST From: BEAME@SSCvax.McMaster.CA Subject: Proxy ARP, routing and Internet Addresses To: TCP-IP@SRI-NIC.ARPA X-VMS-To: IN%"TCP-IP@SRI-NIC.ARPA",BEAME At McMaster University we have about 600 host (PCs and others) on our bridged ethernet. We also have a growing number of subnets which usally consist of one SUN server with two network controllers and several diskless clients. We are in the process of connecting to a network which will require "real" Internet Addresses (we have been using 1.x.y.z). We feal that a single Class B address cannot handle the growing number of hosts (over 1024 by year end and around 30 SUN sub-networks). The solution that I can understand is the aquasition of two Class B addresses, using one for the main network and subnet the other into 255 sub-networks with 254 hosts each. I understand what Proxy ARP does, but I don't know if it can (or how it can) be used to allow us to need only one Internet address. If I am totaly out in left field, please say so and I will request two numbers. -Carl Beame Beame@McMaster.CA Beame@McMaster.BitNet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805311807.AA03452@ucbvax.Berkeley.EDU] <1988053114123300> From: ahd@OMNIGATE.CLARKSON.EDU (MESSAGE AGENT) Newsgroups: comp.protocols.tcp-ip Subject: Re: Gateway to Net Ten Message-ID: <8805311807.AA03452@ucbvax.Berkeley.EDU> Date: 31 May 88 14:12:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 42 This is an automatic reply. Feel free to send additional mail, as only this one notice will be generated. The following is a prerecorded message, sent for ahd 27 November 1987 I don't know what to say in this, my last note from Buffalo, New York. Good and bad things have happened to me since the end of October that defy description, and the only people who would believe me already have enough stories to tell about me without creating new legends. The people who made the good things happen know who they are, and as for the bad things... I prefer to lump them together as acts of God and leave it at that. However, the end result of those past four weeks is that I now have survived my first week working for AGS Information Services on site at IBM Kingston preparing to change software that I'm not allowed to discuss, I enjoy the work, and I expect it to last a while. I also have found an apartment in Kingston, and will be tearing down my computer to be moved there as soon as I log off. My new address as of 1 December 1987 is: Andrew H. Derbyshire 578 Broadway, Apt 6 Kingston, NY 12401 My telephone will be hooked up on 4 December, and the number will be: 914-339-7425 Note that use of either of these is better than sending me mail on omnigate, because now that I am working I intend on letting my online mail exchanges die a natural death and use real world communications instead. This advice applies to answering this letter, so please send me a holiday greeting at 578 Broadway instead of answering this online. Most of all though, don't be a stranger. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988053119310000> Received: from GRAD.CIS.TEMPLE.EDU by SRI-NIC.ARPA with TCP; Tue, 31 May 88 21:33:35 PDT Date: Wed, 1 Jun 88 00:31 EST From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA Your message could not be delivered to: STAFFORD Your message has been enqueued and undeliverable for 3 days. The mail system will continue to try to deliver your message for an additional 9 days. The beginning of your message follows: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805312243.AA09157@ucbvax.Berkeley.EDU] <1988053120150400> From: TS1347@OHSTVMA.BITNET (Tim A Scott) Newsgroups: comp.protocols.tcp-ip Subject: BAYNESRT@v880np.NEWPORT Message-ID: <8805312243.AA09157@ucbvax.Berkeley.EDU> Date: 31 May 88 20:15:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Mr. Baynes address on the From: line is incorrect. Please send to: baynesrt%v880np.decnet@nusc-npt.arpa Tim Scott Postmaster at OSU ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1112@thumper.bellcore.com] <1988053120413700> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Linking LAN's via Public X.25 Summary: Other IP-on-X.25 gateways Message-ID: <1112@thumper.bellcore.com> Date: 31 May 88 20:41:37 GMT References: <13652@comp.vuw.ac.nz> <8805282211.AA02054@sluggo.sun.com> Organization: Bell Communications Research, Inc Lines: 64 While we have not used Sun's Sunlink-X25 product, we used the CSNET X25NET software on a VAX and a GTE Telenet X.25 link for some time. Then we upgraded our Internet membership from Steerage Class to First Class by junking X25 and getting a direct HDH connection to an ARPANET PSN. So I think I can make a few general comments from our experiences in running IP over X.25. Yes, it works. But the fact that it does reflects more on the flexibility and robustness of TCP/IP than on any inherent suitability of X.25 for serious computer networking (as opposed to remote slow speed terminal multiplexing, which is what X.25 was designed for and actually does reasonably well). An IP-on-X.25 gateway is a complex beast, mainly because of X.25's many gratuitous complexities. The most obvious is the need to manage connections. Interfaces usually support only a limited number of them. Worse, carriers may decide to charge you for keeping them open even if they're idle. (Fortunately, Telenet doesn't do this. I guess they're satisfied with the $1500 you pay them every month just to have a 9600 bps host access line to their network. This is exclusive of usage sensitive packet charges, more about them later). The usual strategy here is to keep your list of open connections sorted in order of time of last use, so you can close the least recently used connection should you need to open another one. Timers can also be used to close idle connections. Other problems include inherent performance bottlenecks imposed by the carrier's own interpretation of the X.25 protocol. For example, Telenet acts as though the "D-bit" (delivery confirmation bit) in each packet is set. This means that their packet-layer acknowledgements are on an end-to-end basis. Unfortunately, the packet size is limited to 128 bytes, and the packet layer window is only 2 packets. This means you can't send more than 256 bytes on any single virtual circuit per network round trip time. This can severely limit throughput; in our experience we could seldom use more than 1/4 of the bandwidth of our 9600 bps access line with any one virtual circuit. Since almost all of our IP traffic was to one destination (relay.cs.net) this would have been a serious performance bottleneck except for a feature in the gateway code that opened multiple, parallel X.25 virtual circuits to the same destination and dealt outgoing packets to them in round-robin fashion. Tannenbaum calls this "downward multiplexing"; I call it a "kludge". (By the way, this feature comes in very handy when implementing TCP. There's no other Internet path that gives you such a chance to test your packet resequencing code!). But wait, there's more! Not only is an X.25 gateway inordinately complex, but running it can be very expensive. Telenet, as do all X.25 carriers that I'm aware of, charges for each packet sent. There is a nighttime discount, but the figures are still quite high. If you examine the tariffs, you will find that shipping large files over X.25 can be *very* expensive. In fact, it is considerably cheaper to use one of the new 9600 bps dialup modems -- as low as HALF the cost of X.25. Just to give you an idea, the last month before we dumped it in favor of our ARPANET connection, our X.25 path to the Internet through Telenet and relay.cs.net cost us $10,000. And we did NOT run routing packets over the path. Even a leased line to Cambridge would have been considerably cheaper. Based on my own experiences with IP over X.25, one must wonder what they were smoking down at the Pentagon when the DoD decided to specify X.25 as the standard interface to the DDN. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806010019.AA10897@ucbvax.Berkeley.EDU] <1988053123520000> From: BEAME@SSCvax.McMaster.CA Newsgroups: comp.protocols.tcp-ip Subject: Proxy ARP, routing and Internet Addresses Message-ID: <8806010019.AA10897@ucbvax.Berkeley.EDU> Date: 31 May 88 23:52:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 At McMaster University we have about 600 host (PCs and others) on our bridged ethernet. We also have a growing number of subnets which usally consist of one SUN server with two network controllers and several diskless clients. We are in the process of connecting to a network which will require "real" Internet Addresses (we have been using 1.x.y.z). We feal that a single Class B address cannot handle the growing number of hosts (over 1024 by year end and around 30 SUN sub-networks). The solution that I can understand is the aquasition of two Class B addresses, using one for the main network and subnet the other into 255 sub-networks with 254 hosts each. I understand what Proxy ARP does, but I don't know if it can (or how it can) be used to allow us to need only one Internet address. If I am totaly out in left field, please say so and I will request two numbers. -Carl Beame Beame@McMaster.CA Beame@McMaster.BitNet ----MESSAGE-END----