----MESSAGE-BEGIN---- [8607011106.AA19635%40nrl-css.ARPA] <1986070103063200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: dardy@NRL-CSS.ARPA (Hank Dardy) Newsgroups: mod.protocols.tcp-ip Subject: Re: Am I imagining things? Message-ID: <8607011106.AA19635@nrl-css.ARPA> Date: Tue, 1-Jul-86 07:06:32 EDT Article-I.D.: nrl-css.8607011106.AA19635 Posted: Tue Jul 1 07:06:32 1986 Date-Received: Wed, 2-Jul-86 00:02:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa We see the same behavior here. Haven't figured out cause. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607011443.AA28612%40ucbvax.Berkeley.EDU] <1986070105002900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: brescia@BBNCCV.ARPA (Mike Brescia) Newsgroups: mod.protocols.tcp-ip Subject: Re: Am I imagining things? Message-ID: <8607011443.AA28612@ucbvax.Berkeley.EDU> Date: Tue, 1-Jul-86 09:00:29 EDT Article-I.D.: ucbvax.8607011443.AA28612 Posted: Tue Jul 1 09:00:29 1986 Date-Received: Wed, 2-Jul-86 00:02:44 EDT References: <12219087923.5.MRC@SIMTEL20.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa You aren't the first person to have complained about this. I investigated it as a TOPS-20 problem but then I got reports that it happened in FTP transfers that didn't involve any TOPS-20 systems. Can you name a site to which an FTP hangs from your host, and another to which it does not fail? You could also list the gateway(s) through which your connection passes. Can you examine the TCP layer and IP layer statistics for signs of retransmissions or missing acks (TCP) or discarded unreassembled fragments (IP) or any other counters that are out of the mainstream? I would like to see some indication from the host ends that the problem either could or could not be caused by a gateway. Mike Brescia ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607020249.AA18771%40ecsvax] <1986070118495800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hes@ecsvax.UUCP (Henry Schaffer) Newsgroups: mod.protocols.tcp-ip Subject: Reading List? Message-ID: <8607020249.AA18771@ecsvax> Date: Tue, 1-Jul-86 22:49:58 EDT Article-I.D.: ecsvax.8607020249.AA18771 Posted: Tue Jul 1 22:49:58 1986 Date-Received: Sun, 20-Jul-86 03:59:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa I've read M. A. Padlipsky's book, "The Elements of Networking Style", and I've also read (er, looked at) a number of RFCs. With the RFCs I find it hard to see the forest for the trees, and "Elements" is not a tutorial (nor meant to be one.) Can anyone suggest a tutorial Reading List on the tcp/ip suite of protocols. With the adoption of tcp/ip by the NSF for NSFnet, there will probably be many people needing such a reading list. --henry schaffer n c state univ TSCHES@TUCC.BITNET ...mcnc!ecsvax!hes (uucp) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607020415.AA11796%40ucbvax.Berkeley.EDU] <1986070119253500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: eichelbe@NADC Newsgroups: mod.protocols.tcp-ip Subject: NIC host table changes - how to survive? Message-ID: <8607020415.AA11796@ucbvax.Berkeley.EDU> Date: Tue, 1-Jul-86 23:25:35 EDT Article-I.D.: ucbvax.8607020415.AA11796 Posted: Tue Jul 1 23:25:35 1986 Date-Received: Wed, 2-Jul-86 21:14:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 63 Approved: tcp-ip@sri-nic.arpa In regard to the changes in the host table to fully support domains: Yes, this is "breaking" the mail system at some sites. Due to legal problems which I won't discuss here, I am stuck with an smtp mail system on a 4.1 BSD UNIX system for a VAX 11/780. Going to 4.2 BSD or 4.3 BSD (which I assume will support the domain stuff) is not presently and may never be an option for my site. Since I do have source code and I am a C programmer, fixes to the source are possible. Does anyone have an idea of the magnitude of the changes that are required? (That was not a rhetorical question!) I'd be interested in some informal help. The code looks like it was originally produced by BB&N since the code has bug fixes in it which are labeled as from BB&N. When I called BB&N they told me that they were not supporting the code. Although I can make the mail headers for my /usr/spool/netmail/arpa* files (mail to be sent) have the complete system name (e.g., aim.rutgers.edu) the smtp mailer says that no such site exists. This is evidenced by the command "host" which is supossed to return information from the host table existing on MY system when a site name is provided. If I type: host nadc I get back: nadc.arpa nadc:26.0.0.24 hostcap=1 tcp/ftp tcp/smtp tcp/telnet which is fine. But it has always been true for my "host" command that typing: host nadc.arpa returned: host: bad host: network not found and typing: host ru-aim returns: aim.rutgers.edu ru-aim ru-aim.arpa:128.6.4.15 hostcap=1 tcp/finger tcp/ftp tcp/smtp tcp/telnet but typing: host aim.rutgers.edu returns: host: bad host: too many address components --- So it becomes obvious that low-level routines in the mailer do not under- stand domain-type information. Are code changes required? Maybe there is something I should be placing in my NETWORKS file to tell the mailer about .arpa and .edu? The mailer has obviously always assumed .arpa. Any help or ideas on what I can do to join everyone else here in 1986 would be appreciated. Thank you. Jon Eichelberger eichelbe@NADC.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860702.170938z.12884.wales%40DIANA.LOCUS.UCLA.EDU] <1986070209093800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: wales@LOCUS.UCLA.EDU (Rich Wales) Newsgroups: mod.protocols.tcp-ip Subject: Re: NIC host table changes - how to survive? Message-ID: <860702.170938z.12884.wales@DIANA.LOCUS.UCLA.EDU> Date: Wed, 2-Jul-86 13:09:38 EDT Article-I.D.: DIANA.860702.170938z.12884.wales Posted: Wed Jul 2 13:09:38 1986 Date-Received: Thu, 3-Jul-86 07:02:46 EDT References: <8607020415.AA11796@ucbvax.Berkeley.EDU> Sender: daemon@styx.UUCP Reply-To: ucla-cs!wales@ucbvax.Berkeley.EDU (Rich Wales) Organization: UCLA Computer Science Dept. Lines: 80 Approved: tcp-ip@sri-nic.arpa In article <8607020415.AA11796@ucbvax.Berkeley.EDU> eichelbe@NADC.ARPA writes: > In regard to the changes in the host table to fully support domains: > > Yes, this is "breaking" the mail system at some sites. . . . I am > stuck with an SMTP mail system on a 4.1 BSD UNIX system for a VAX > 11/780. . . . Since I do have source code and I am a C programmer, > fixes to the source are possible. . . . The code looks like it was > originally produced by BBN. . . . I assume you were one of those sites whose legal staff refused to go along with some of the disclaimer language in Berkeley's 4.2/4.3 license agreements. I remember that unfortunate problem. In any case . . . we (at UCLA) ran the BBN network code on a 4.1BSD system for some time here, and I modified it to accept domain naming. (We have since scrapped the BBN code in favor of a combination of 4.2BSD network code and home-grown mail software.) I don't know where our old modified sources are any more, so I can't simply send them to you, but I think I remember bits and pieces of what I had to do to get the stuff to work. > Although I can make the mail headers for my /usr/spool/netmail/arpa* > files (mail to be sent) have the complete system name (e.g., > aim.rutgers.edu), the smtp mailer says that no such site exists. This > is evidenced by the command "host". . . . It has always been true for > my "host" command that typing: > > host nadc.arpa > > returned: > > host: bad host: network not found > > and . . . typing: > > host aim.rutgers.edu > > returns: > > host: bad host: too many address components > > So it becomes obvious that low-level routines in the mailer do not > understand domain-type information. Are code changes required? > Maybe there is something I should be placing in my NETWORKS file to > tell the mailer about .arpa and .edu? The mailer has obviously > always assumed .arpa. > > Jon Eichelberger > eichelbe@NADC.ARPA In our case (and presumably in yours as well), the problem turned out to be that the BBN host-name routines interpreted something like XXX.YYY as meaning "host XXX, using an address on network YYY". In today's world of domain naming, this is completely bogus. Some early -- or not-so- early -- domain-naming implementations still incorporated this idea, though -- as evidenced by names of the form *.UUCP, *.CSNET, *.BITNET, etc. Even today, a handful of mail systems still in use continue to insist (incorrectly) that ".ARPA" may freely be added to -- or removed from -- any Internet host name at will. I no longer have our old sources readily available, as I said, but my recollection is that I fixed this problem by redefining the "host.net" notation in the BBN library routines to use a dollar sign instead of a period (i.e., "host$net"). I may also have had to fiddle with some other parts of the code in order to allow periods to be part of a host name. This is about as specific as I can remember. I hope it helps. I would *NOT* recommend trying to get around your problem by adding extra entries to your network list. Even if such an approach would work (and, believe me, it wouldn't), domain naming has nothing whatever to do with physical networks; the existence of a name like "PODUNK.EDU" does *NOT* mean that there is a network somewhere called "EDU". -- Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA wales@LOCUS.UCLA.EDU ...!(ucbvax,ihnp4)!ucla-cs!wales "Sir, there is a multilegged creature crawling on your shoulder." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607030023.AA11136%40amdahl] <1986070216235000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sjl@amdahl.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: IEEE 802 and ISO Message-ID: <8607030023.AA11136@amdahl> Date: Wed, 2-Jul-86 20:23:50 EDT Article-I.D.: amdahl.8607030023.AA11136 Posted: Wed Jul 2 20:23:50 1986 Date-Received: Thu, 3-Jul-86 08:17:13 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 47 Approved: tcp-ip@sri-nic.arpa Newsgroups: mod.protocols.tcp-ip Summary: Don't get your knickers in a twist References: <860626161800.4.DCP@FIREBIRD.SCRC.Symbolics.COM> Reply-To: sjl@amdahl.UUCP (Steve Langdon) Organization: Amdahl Corp, Advanced Systems Planning Keywords: 802 SNAP LSAP ARP protocol_id In article <860626161800.4.DCP@FIREBIRD.SCRC.Symbolics.COM> DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) over-reacts to a missguided belief that the standards community is not providing a usable alternative to the protocol ID field that was present on Ethernet. The current proposal is that a reserved LSAP will be defined to identify a Network Layer entity that operates a subnetwork access protocol which provides the protocol ID function. The protocol header is five octets; the first three octets identify an organization (using the same values as those used in the first part of the MAC address), and the remaining two octets replace the old protocol ID. > Aren't they also snobbish enough not to need ARP? Don't you just "send > it" and it "magically" gets there? While the OSI network address structure does not suffer from the length limitions of the Arpa IP, an ARP equivalent is seen as useful. For this reason ANSI ASC X3S3.3 has developed a protocol that provides ARP and ICMP redirect type functions. The US submitted this proposal to ISO a year ago and it has been discussed at two ISO TC/97 SC 6 WG2 meetings. We hope that it will be balloted as a Draft Proposal following the meeting of SC 6 this October. X3S3.3 is also working on EGP/GGP type functions for use with the ISO IP. > I just realized what's ticking me off. This whole nonsense is a > parallel with puritanical religions. It does not have any room for > person freedom (e.g., elbow room for new protocols) and it doesn't have > any concept of social responsibility (e.g., maybe topic> isn't such a good idea, but AT THIS TIME IN THIS SOCIETY it is a > necessary evil). Time to nail a grievance to somebody's door? No. It would be much more useful if you would participate in the process of developing standards so that you could make sure that pragmatic considerations are not ignored. Flaming when you do not have accurate information is not going to help solve the problems which do exist. Stephen J. Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl [ The article above is not an official statement from any organization in the known universe. ] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607030528.AA02815%40ucbvax.Berkeley.EDU] <1986070221312600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mills@DCN6.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Sources for radio clocks Message-ID: <8607030528.AA02815@ucbvax.Berkeley.EDU> Date: Thu, 3-Jul-86 01:31:26 EDT Article-I.D.: ucbvax.8607030528.AA02815 Posted: Thu Jul 3 01:31:26 1986 Date-Received: Thu, 3-Jul-86 23:12:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 131 Approved: tcp-ip@sri-nic.arpa Folks, From the vast volume of inquiries received here, it seems a number of players may be hooked on the time game. For them the following list of timetickers is recommended as a source of radio clocks. All of the radio clocks listed consist of a lunchbox-size gadget with an antenna connector at one end and a serial RS-232 connector at the other. You mount the antenna on the roof, snake the feedline down the elevator shaft and plug into the gazinta side, then plug the gazouta side to a spare serial port on a friendly host, say at 1200 bps. All the clocks provide an ASCII serial timecode message, some in response to a poll character, some gratuitously. All include a flashy LED display which can be peeked through the machine-room window for everybody to set their watches by. It should be understood that the technology with which all of these clocks operate is not completely reliable. Extensive experience with all of these clocks suggests that gross errors can sometimes occur, even in the most accurate and expensive models. The only solution to this problem is redundancy, perhaps along the lines suggested in RFC-958. ------------------------------------------------------------------------------ Model 468-DC Satellite Synchronized Clock Kinemetrics True Time Division 3243 Santa Rosa Avenue Santa Rosa, CA 95401 (707) 528-1230 Source: GOES geosynchronous satellite (468 MHz) Accuracy: 0.1 ms nominal Price: about $2500 with antenna This clock is synchronized by signals transmitted from a Geosynchronous Orbit Environmental Satellite (GOES), two of which were originally positioned over the eastern and western sides of the country, but only one is believed in operation now. With the present uncertainty in the space program, it is not clear that this service can survive forever. The antenna is a UHF planar array (a high-gain helical antenna is an option), which must be positioned for line-of-sight access to the satellite and connected to the receiver with low-loss coaxial cable. The receiver is relatively immune to radio propagation conditions and electrical storms. ------------------------------------------------------------------------------ Model 8170 WWVB Synchronized Clock Spectracom Corporation 101 Despatch Drive East Rochester, NY 14445 (716) 381-4827 (Tom Donaher) Source: WWVB Boulder, Colorado (60 kHz) Accuracy: 0.1 ms nominal Price: $2250 plus $250 for antenna This clock is synchronized to signals transmitted by the WWVB LF radio station in Boulder, Colorado. This is probably the most reliable and accurate source of NBS radio time at present, but can be subject to occasional service interruptions due to radio propagation conditions and electrical storms. The antenna consists of a tee-shaped ferrite rod mounted on a short boom, which can be mounted on the roof clear of metal obstructions, but not necessarily with line-of-sight access to the transmitter. An "on-time" signal generated by the receiver can be used in conjunction with the serial ASCII timecode, but this is important only for accuracies in the ten-millisecond range or better. ------------------------------------------------------------------------------ Model GC-1000 Most Accurate Clock with Model GCA-1000-1 RS-232C Output Accessory Heath Company Benton Harbor, MI 49022 Source: WWV Ft. Collins, Colorado, or WWVH Maui, Hawaii (5/10/15 MHz) Accuracy: 100 ms nominal (when synchronized) Price: about $300 kit, $425 assembled and tested This clock is synchronized to signals transmitted by the WWV or WWVH HF radio stations in Ft. Collins, Colorado and Maui, Hawaii, respectively. This is the least reliable and accurate (and cheapest) source of NBS radio time at present, but is subject to frequent service interruptions due to radio propagation conditions and electrical storms. The receiver normally scans three of the five WWV/WWVH broadcast fequencies (5/10/15 MHz) and locks to one of them as available. Since the eleven-year sunspot cycle, which is the primary determinant of radio propagation conditions, is presently near its minimum, and conditions during Summer are usually the worst, the receiver can coast for days without locking to the transmitter. During such periods the accuracy can degrade to the order of seconds. A suitable antenna clear of metal objects and RFI generated by computing machinery is vital for acceptable performance. This normally takes the form of a wire dipole, perhaps 10-30 meters long strung between poles and fed with coaxial cable and a balun. Any amateur operator or shortwave enthusiast knows exactly how to construct and install such a thing. ------------------------------------------------------------------------------ There are many other sources of radio time, but few suitable radio clocks are known to be available for them. These include: Canadian standard-time station, CHU Ottawa, Ontario, operates on 3330, 7335 and 14670 kHz and ordinarily provides more reliable service than WWV/WWVH, at least on the East coast. However, its signal format is not compatible with WWV/WWVH. There very likely may exist sources for radio clocks which operate using this station. United Kingdom standard-time station MSF also provides time signals for which at least one radio clock (last known residence at University College London) exists. Some local TV stations, including Channel 5 in the Washington area, are synchronized to precise standards (this happened in response to NBS prodding some time ago). The major TV networks are also synchronized to these standards; however, their local affiliates often operate using frame buffers which allow local origination without frame-slipping when switching to and from the network feed. This of course distroys the usefulness of the method. While those stations that are synchronized can be used to calibrate local time standards, they are unsuitable as a regular source of time. The many Loran-C navigation stations operated by the Coast Guard and scattered throughout the world transmit pulse-coded signals on 100 kHz and are synchronized precisely to NBS time. While a byproduct of accurate navigation is accurate time (and vice versa), the specialized receivers, some of which are turning up at surplus outlets, would need extensive modification to serve as radio clocks. The several Omega navigation stations operated by the Navy and providing worldwide service transmit continuous-wave signals on discrete frequencies in the 10-13 kHz (!) range and are synchronized precisely to NBS time. Very special receiving equipment is required, which is probably not suitable to radio clocks. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607061657.AA12520%40ucbvax.Berkeley.EDU] <1986070608582400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BEAME@MCMASTER.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: An out of the blue query. Message-ID: <8607061657.AA12520@ucbvax.Berkeley.EDU> Date: Sun, 6-Jul-86 12:58:24 EDT Article-I.D.: ucbvax.8607061657.AA12520 Posted: Sun Jul 6 12:58:24 1986 Date-Received: Sun, 6-Jul-86 23:53:37 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Hi, Could someone please send me via the network the specifications for the R.A.R.P (Reverse ARP) protocol ? - Thanks Carl Beame - BEAME@MCMASTER.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607062057.AA14386%40ucbvax.Berkeley.EDU] <1986070612424700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MILLS@D.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: An out of the blue query. Message-ID: <8607062057.AA14386@ucbvax.Berkeley.EDU> Date: Sun, 6-Jul-86 16:42:47 EDT Article-I.D.: ucbvax.8607062057.AA14386 Posted: Sun Jul 6 16:42:47 1986 Date-Received: Sun, 6-Jul-86 23:56:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa In response to the message sent 6 JUL 86 12:45-EDT from BEAME%MCMASTER.BITNET@WISCVM.ARPA Carl, You want RFC-903, which is available from the NIC. If everybody believed your request and complied, you would see a personal example of what is called meltdown on an Ethernet. If you can tell everybody else except me not to respond, I would be glad to mail the RFC to you. Think about that... Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607070552.AA18979%40ucbvax.Berkeley.EDU] <1986070621541700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mills@DCN6.ARPA Newsgroups: mod.protocols.tcp-ip Subject: On routing freedom and statutes of liberty -or- Ether is a gas Message-ID: <8607070552.AA18979@ucbvax.Berkeley.EDU> Date: Mon, 7-Jul-86 01:54:17 EDT Article-I.D.: ucbvax.8607070552.AA18979 Posted: Mon Jul 7 01:54:17 1986 Date-Received: Mon, 7-Jul-86 07:36:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 428 Approved: tcp-ip@sri-nic.arpa Folks, Don't start the following story unless you enjoy solving puzzles and have a few minutes to study and reflect on the issues. Be advised it is highly technical, not without personal bias and may leave some of you with elevated cranial energies. I especially would like our ANSI/ISO protocol designers to take this thing into their committees and spread mischief (Overheard in X3.S3: "Ya mean those Internet buzzards are doing THAT!?"). The cast of characters includes the NSFnet Backbone, which is now being installed between six Supercomputer sites, plus a bunch of Ethernets at those sites. Some of the sites are also interconnected via the USAN net, which uses a multiple-access Vitalink/TransLAN satellite channel, and some are connected to the ARPAnet via the Ethernets and other nets and gateways. The Backbone gateways, as well as some of the USAN and ARPAnet gateways involved, consist of LSI-11 "fuzzball" systems, which are reasonably good players of the ARP and ICMP game, as well as run their own routing algorithm. The following schematic shows the configuration of these swamps expected by late August. All of the nodes and lines shown are already installed, except for some Backbone line-interface equipment. All of the non-Backbone nodes have been in operation for some time, while three of the Backbone nodes (SDSC, NCAR, Cornell) are presently interconnected and in operation. Only the fuzzballs are shown, since this discussion concerns primarily them; however, you should recognize there are lots and lots of other hosts on these nets and that some nets include many different media besides Ethernets. +---ARPAnet | ====0==== ==0===0== ====0==== 192.17.47| 128.84.253| 128.121.50| ===== Ethernet +---+---+ +-----+-+ +---+---+ ----- serial line | | 56 | | 56 | | (speeds in kbps) NCAR +-------+ CTC +-------+ JVNC | | | | | | | +-+---+-+ +-------+ +---+---+ | | 56 | 56| +-------------+ |56 | | | +-+-----+ +---+---+ +---+---+ +-------+ | | 56 | | 56 | | 56 | | SDSC +-------+ UIUC +-------+ CMU +-------+ UMD | | | | | | | | | +---+---+ +---+---+ +-----+-+ +---+---+ 192.12.207| 192.17.5| 128.2.49| 128.8.1| ====0==== ====0==== ==0===0== ==0=0=0== | | | NSFnet Backbone +---ARPAnet | +---ARPAnet . . . . . . . . . . . . . . . . . . . . . . . . . . | | FORDnet . UMICHnet . | +---MILnet . . | +-------+ . +-------+ +-------+ . +-+-----+ | | 4.8 | | 120 | | . | | FORD14 +-------+UMICH3 +-------+USAN-GW| . | UMD1 | | | . | | | | . | | +-----+-+ . +-----+-+ +---+---+ . +---+---+ 128.5.0| . 35.1.1| 192.17.4| . | ==0===0== . ==0===0== ====0==== . | | . | USAN . | +-+-----+ . +-+-----+ (9 sites) . | | | . | | . | FORD1 | . |UMICH1 | . |4.8 | | . | | . | +---+---+ . +---+---+ . UMDnet| . . . . . | . . . . . . . | . . . . . . . . . . . . . . . | . . . DCnet |9.6 |9.6 | +---+---+ +---+---+ | | | | | | DCN8 | | DCN5 +---------------------------+ | | | | +---+---+ +---+---+ | 128.4.0 | ====0=======0=======0==== | +---+---+ | | DCN1 +---ARPAnet | | +-------+ The players are: NCAR National Center for Atmospheric Research CTC Cornell Theory Center (hardware integration and net operator) JVNC John von Neumann Center SDSC San Diego Supercomputer Center UIUC University of Illinois/University of Chicago (project management) CMU Carnegie-Mellon University UMD University of Maryland (software integration) UMICH University of Michigan (installation and test) DC Fuzzball creche in Vienna, VA FORD Ford Scientific Research Labs in Dearborn, MI At the moment, all of the ARPAnet/MILnet gateways except DCN1 (aka DCN-GATEWAY) include only their own directly-connected client nets in EGP updates sent to core gateways. DCN1 temporarily includes some of the other nets for debugging and test purposes. Therefore, traffic for the other nets must wander to DCN1 and swamp-fuzzball trail to USAN and Backbone trunks (UMD is presently not operational). Eventually, Backbone connectivity may be provided to the ARPAnet by one or more gateways at CMU, CTC or UMD as well. Also at the moment, the Ethernets at some Backbone sites are connected via USAN to each other and via USAN-GW at UMICH to the Interworld. As you can see, there will be a lush supply of routes available, with many sites enjoying connectivity via the Backbone, USAN and ARPAnet paths simultaneously. Believe it or not, traffic actually flies these airways, although sometimes landing in very strange airports. The fuzzballs shown operate an adaptive routing algorithm which selects primary routes based on minimum delay and can select alternate routes based on IP type-of-service field and other factors. Casual observation of the DCnet Ethernet reveals there may be a lot of local-site problems yet to solve. For instance, I spotted two hosts on Cornell local nets working each other via the DC Ethernet (!?!) the other day. Ya gotta see to believe. The ring of hosts and Ethernets at DCnet, UMICHnet and FORDnet has been a valuable prototyping facility, which is its primary service function. Alternate routing in case of failure requires ICMP Redirect and ARP functions to work properly, both in the fuzzballs and in other network hosts, which are represented by a wide variety of VMS, Unix and related systems. A problem in this area is what prompted this message. Recently, Hans-Werver Braun of UMICH and I endured scary experiences while teaching Etherbunnies, fuzzygators and other strange creatures to swim in these swamps. Especially enlightening was USAN, with its nine rambunctious Ethernets, all piled onto the same channel and babbling everything from DECnet and XNS mumbles to Unix rwho shrieks zipping about like lost cosmic particles. It took us two weeks at DefCon 5 to harden the fuzzball silos (which added a couple of dB of their own routing broadcasts) and make space safe for Backbone debug and test. Some of the lessons learned have already been broadcast for public enjoyment and may even have medicinal value. Additional observations are herewith submitted for your entertainment, education and as a basis for comments and suggestions. What I hope we all get out of this exercise is not so much a blueprint for how to deal with the incredibly complicated brushfires we know are circling the horizon (to quote Dave Clark), but rather as an experiment and proof-of-concept suggesting generic issues that need further study and resolution before we send out the fire brigade. Multiplexed Ethernets Most of the interesting lessons were learned on USAN, which radio amateurs will recognize as similar to the pileup when Pitcairn Island shows up on 20 meters. The USAN design was never intended to handle the bedlam of nine simultaneous flocks of squawking rhos, rips and other broadcast honkers, much less the blatant ICMP squawks from the poor creatures that don't understand them. The problem is, of course, that those of us who jimmied the Ethernet protocols while draining our own swamps never thought of making a single cable safe for multiple nets and subnets at the same time. Hans-Werner and I found it useful to forget that the cable is normally protected from crosstalk between neighbor nets and pretend it is a willy-nilly-access packet-radio channel instead. You may not like this model and prefer a much more carefully regimented and regulated approach. We would like to understand what-if first and learn all we can before the wires are insulated and the lessons have to be relearned under meltdown conditions when the insulation wears off somewhere. Even if we agree multiplexed Ethernets are beyond the pale, this exercise may reveal how to harden the hosts and gateways against rogues (and jammers) that might occur from time to time. Therefore, we simply connected everything up and let the packets fly. Hans-Werner and I are still catching our breath, some wheezes of which can be found in the following. We are putting together an almanac, which may appear as a footnote to RFC-985, to teach lessons something like the following: Multiplexed Ethernets are extremely complex and delicate, but may represent a useful solution in exceptional cases. If you are silly enough to contemplate such folly, do it in the following way... Type-of-Service Routing Our research community has been stalking the type-of-service routing issue for awhile now and may have fallen in the wrong pits. It turned out to be easy for the fuzzballs to take a first cut at this simply by extending the address fields in the routing tables to include the IP type-of-service field (actually, the extension consists of a single octet, with each bit corresponding to each of the eight combinations of the Throughput, Delay and Reliability bits). The hard part begins when you try to make ARP, ICMP error messages and ICMP Redirects work in that model. The goal would be to maintain possibly separate routes for every combination of type-of-service specification. The main problem is that the packet formats are not rich enough to distinguish this information to the detail required. In addition, much of the existing host software must be changed in nontrivial ways (e.g. the ARP cache gets an extra octet, etc.). The fuzzball routing data structures already include such provisions, but the algorithms have not been evolved to exploit them yet. Alternate Routes It was our intention to explore the consequences of trying to provide alternate routes should something quit and where not all paths were monitored by the fuzzball routing algorithm. For instance, if a backbone trunk were broken, it might be possible to route out the ARPAnet and back in again (please table administrative discussion - we just want to explore how the darn thing might work, not whether it would be allowed or not). As an experiment, The fuzzballs were fiddled so that, if an internal link controlled by the fuzzball routing algorithm broke, traffic could be directed via a designated backup path. This was tested in the DCN5 - UMD1 link, with designated backup path via the ARPAnet/MILnet gateways on each net, which is ordinarily controlled by EGP and the core system. The effect is that, when the DCN5 - UMD1 link is up, traffic flows via it, but, when the link is down, traffic flows the long way around via ARPAnet, MILnet and thousands of gateways. This was a cute experiment and worked just fine; however, its success depends on carefully engineered tables and delicate assumptions about the functionality and dynamics of both the fuzzball and EGP algorithms. More study and experiment is needed here. Subnets All of the class-B nets shown in the schematic are subnetted, with the third octet interpreted as the subnet number. The class-A UMICHnet is subnetted as well. Good subnetting practice is to avoid the use of subnet-number fields containing all zero bits or all one bits, since this can lead to confusing interpretation of broadcast scope, for example. DCnet and FORDnet fall victim to this observation. I can't believe for a minute that vendor products without subnetting capability will have a long life in this era. Broadcast and Don't-Know Addresses The Internaut Handbook specifies that the local-subnet address with all ones in the host portion should be interpreted as "broadcast" and that the address with all zeros should be interpreted as "don't know." Under these interpretations, the former is legal only in destination-address fields, while the latter (used by a diskless workstation while RARPing for its address, for example) is legal only in source-address fields. Where subnets are in use, the scope of this interpretation extends only to the given subnet, if the subnet-number field is neither all zeros or all ones, and to the entire network of subnets if either or all zeros or all ones. We observed numerous abuses of this model, including the use of zeros as the broadcast address (older bsd Unix) and various tangles with broadcasting in a subnet environment. In point of fact, it doesn't matter which convention is followed in a particular subnet, as long as all hosts and gateways on that subnet understand which is in use, as well as the subnet mask, and agree never to propagate either local-broadcast or local-don't-know datagrams beyond the gateways. The same consideration applies at the network-of-subnets level, of course. For reasons that should be evident from the following, I believe the use of zeros and ones in the subnet-number field and the above interpretation should be avoided in favor of explicit broadcast agents. One implication of this model is that broadcasts would never be propagated by a gateway. I further believe that a very careful coupling should be maintained between the semantics of the Ethernet broadcast/multicast addresses and IP broadcast addresses; otherwise, the implementation is forced not only to carry all kinds of wierd semantics up the protocol stack, but its error detection is seriously handicapped as well. A paranoid receiver may well check that, when an IP packet with an Ethernet broadcast/multicast destination address arrives, the destination-address field must contain the IP subnet-broadcast address or the packet is discarded. This would have the effect of disallowing random Ethernet broadcasts to designated IP destinations if the sender had a broken or unimplemented ARP, for example. It would also disallow cross-net routing broadcasts, such as the fuzzballs use to manage USAN routing. More thought is needed here. Broadcasting Semantics Nothing we found exhibited stranger behavior than the broadcast semantics of the various Ethernets. The most disruptive thing by far was the tendency of some receivers to "helpfully" relay broadcast packets with destination IP address other than the receiver to their "intended" destination. An innocent rwho from a host on one subnet of a multiplexed cable ignites instant abuse of the gateways if the hosts on another subnet do this. In extreme cases the network can fall into a debilitating, oscillatory state (called meltdown), where the entire cable bandwidth is consumed by these packets. A general principle of nuclear engineering is that reactor meltdown is possible only if more energy gazouta the reactor than gazinta it. Ethernet meltdown cannot occur if it can be gauranteed that no more than one gazouta packet can ever be produced by a single gazinta packet at a node. Thus, a forwarded broadcast packet (hereby named a Chernobyl packet - you first heard it here) can produce meltdown only if more than one receiver is involved. Of course, if a Chernobyl packet is assigned an Ethernet broadcast address, the meltdown would occur within milliseconds. I believe no receiver (host or gateway) should ever forward broadcast packets onward to a subsequent destination, unless the receiver is an explicitly designated broadcast agent which explicitly understands and maintains the spanning trees and routing algorithms necessary to reach the intended destination without meltdowns. What are the groundrules of a broadcast service? Those such as rwho, rip and fuzzball routing do not involve an explicit reply from each of possibly many receivers. Those such as ARP, RARP and ICMP Address Mask may produce a meteor shower of responses if multiple receivers can respond. In some cases where efficiency can be sacrificed for reliability, meteor showers may be acceptable, but in others this would be disruptive. A case might be made for datagram services like the above and maybe others, but this would be silly for connection-oriented services. Experiments with broadcast TCP service and unhardened fuzzballs led to hilarious scenarious leading to marginal meltdown, suggesting that a multiple-destination semantics may have to be carried up the protocol stack anyway, at least for error detection. ICMP Error Messages The Internaut Handbook suggests ICMP error messages should be returned to the ultimate source if a datagram cannot be delivered to its intended destination. Some hosts interpret this literally and return ICMP error messages if the protocol or port fields do not match a service provided by the receiver. We discovered this quickly in the case of the fuzzball routing algorithm, which broadcasts Hello messages on protocol 63 (private use) from time to time, each one creating a shower of ICMP error messages. I believe no receiver (host or gateway) should ever return an ICMP error message unless it can determine with fair reliability that any other copies that might be wandering around the network will be routed by that receiver and that the same ICMP error message would be produced in each case. This is a general statement and applies to scenarios other than broadcast. One implication, for example, is that ICMP error messages must be considered non-deterministic, since one path can be temporarily stoppered-up while the routing algorithm is thrashing and duplicates are successfully negotiating another path. With respect to broadcast, ICMP error messages should never be sent in response to a received broadcast packet. Another way of looking at it is that no message should ever be sent if its semantics would involve the broadcast address as the source address (IP or Ethernet) in the packet. Subnet Masks No gateway implementation known to me (except the fuzzball as of today) supports the ICMP Address Mask messages described in RFC-950. If a gateway joins two subnets, it has to know which subnet the request is for, so it can determine the proper mask. If the requestor knows its own address, it can broadcast the request and the gateway(s) can determine which subnet from the source IP address of the request. If it does not know its own address, it must use RARP to find it (the alternative suggested in RFC-950 is simply too bizzare to contemplate in this environment). This is the only known case that requires broadcast of an ICMP message, which not only complicates the implementations, but suggests that maybe something is broken in the model. The real problem is that the ARP/RARP semantics are simply not rich enough and should be expanded to include the mask in the first place. For instance, a RARP reply should include not only the specific host address, but also the address mask associated with its subnet. Also, if promiscuous ARP is used to bypass a specific gateway address, an ARP reply should include the address mask associated with the subnet the address belongs to (if known). The requisite semantics and packet formats might not be hard to provide, since ARP and RARP are quite generic. While adding the subnet mask, the type-of-service mask should also be added. The ICMP Address Mask messages should be junked. Martian Filters The idea of Martian Filters originated as a weapon to combat datagrams carrying bogus destination addresses (like 127.0.0.0), which can be emitted by broken bsd Unix systems. These datagrams sometimes escape their local net and are found wandering about the Internet and creating a significant hazard to swamp navigation. An unbelievable brew of this stuff was found sloshing over USAN, which prompted my earlier message on this subject. Martian Filters search for "reserved," "broadcast" and "don't-know" addresses identified in the Assigned Numbers list and discard datagrams (without ICMP error notification) to those destinations, unless addressed to the host/gateway directly. Use of this filter prevents the recipient from forwarding a broadcast datagram back onto the cable or sending disruptive ICMP error messages in the case of unknown protocols or ports appearing in broadcast datagrams. We found these filters to be absolutely necessary to avoid chaos (pun) on USAN. When subnets are in use, a receiver may not know that a particular IP address in fact represents a broadcast, except that it presumably came in on a datagram with a broadcast address in the Ethernet destination-address field. The Martian Filter we used is subnet-independent and filters out only the well-known network-level broadcast and don't-know addresses. However, the fuzzballs, at least, know what subnet they are on and grab local-net broadcast and don't-know addresses before they can be sent onward and create mischief. If it can be agreed that the network-of-subnets semantics mentioned above (i.e. disallowed) is correct, then the broadcast and don't-know filters can be implemented more efficiently and effectively. More study and consensus is needed in this area. Asymmetric Paths and Redirects From the above diagram you can see that, when airport DCN8 closes, flights to FORD1 can continue via DCN5, UMICH1/3 and FORD14 as determined by the the routing algorithm. ARPs for FORDnet will then be returned by DCN5 and all other hosts will return IMCP Redirect messages as expected. Now, it turns out that some silly host on UMDnet thinks the slickest airway to FORD1 is out MILnet, back in DCN1 and radar vectors to FORD1, but the DCnet controllers know the smoothest air is via DCN5 and UMD1. Well, all that asymmetry works, too, until such time as DCN8 opens up again. When the routing algorithm finds that DCN8 is open, everything shuffles as expected in DCN5 and DCN8; however, the other DCnet hosts sharing the Ethernet may not realize this, since their minimum-delay path is still via the Ethernet. Ordinarily, these hosts will update their routing tables correctly when they send traffic to FORD1, since DCN5 will redirect that traffic to DCN8. The problem lies in the question: Which local-net host (Ethernet address) does DCN5 send the redirect to? If it doesn't know better, it simply looks in its routing tables for the sender (UMD host) and determines the route via DCN5 to UMD1, but it would be nonsense to send the redirect there. However, the incoming traffic actually came via DCN1, so the redirect should really be sent to it instead. Good implementation technique tries to separate protocol layers cleanly, which suggests Ethernet addresses be propagated no further up the stack than absolutely necessary. Since an ICMP redirect does, after all, have an IP header, the temptation is to treat it like other ICMP messages as a wart on the side of the network (IP) layer. But other ICMP messages don't have this insiduous coupling to the local-network (Ethernet) layer, so no provisions were made in my original design to save the Ethernet addresses at all. Well, I shambled back to the hanger and tinkered the fuzzware, so now all controllers are on the same frequency. My solution was to remember the Ethernet source address as each Ethernet packet arrives and stuff it in the destination address of the outbound ICMP Redirect message. Some of you may remember my previous messages which argued against propagating Ethernet addresses up the stack and suggest I got what I deserved. I am still opposed in principle to spreading local-net layer semantics (like broadcast addresses) outside that layer and believe such semantics should be re-created at the network level (e.g. use IP broadcast address) as necessary. Unfortunately, for reasons mentioned a paragraph or two back, I may have to eat them words. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607071508.AA24325%40ucbvax.Berkeley.EDU] <1986070707093700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mills@DCN6.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Clarification on access control Message-ID: <8607071508.AA24325@ucbvax.Berkeley.EDU> Date: Mon, 7-Jul-86 11:09:37 EDT Article-I.D.: ucbvax.8607071508.AA24325 Posted: Mon Jul 7 11:09:37 1986 Date-Received: Mon, 7-Jul-86 19:33:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Folks, In my recent message on the status of NSFnet, please be advised that those nets mentioned in connection with prototyping and testing, in particular FORDnet and DCnet, are NOT part of NSFnet and are NOT intended to carry any operational NSF traffic whatsoever. These nets were established and are operated strictly for research and development only and do not carry operational traffic for Ford or Linkabit either. In this and many other cases in our proliferating Internet community, there is a big gulf between connectivity, which is determined by architecture and engineering, and access control, which is determined by administrative policy. If you want to dial the President you can, but he might not want to talk to you. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12220800088.43.JED%40CS.COLUMBIA.EDU] <1986070707395200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JED@CS.COLUMBIA.EDU (Jed Schwartz) Newsgroups: mod.protocols.tcp-ip Subject: please remove me from tcp-ip mailing list Message-ID: <12220800088.43.JED@CS.COLUMBIA.EDU> Date: Mon, 7-Jul-86 11:39:52 EDT Article-I.D.: CS.12220800088.43.JED Posted: Mon Jul 7 11:39:52 1986 Date-Received: Mon, 7-Jul-86 19:35:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 Approved: tcp-ip@sri-nic.arpa ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607072024.AA09444%40mitre-bedford.ARPA] <1986070713511800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bjp@MITRE-BEDFORD.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: The availability of the host, ulana Message-ID: <8607072024.AA09444@mitre-bedford.ARPA> Date: Mon, 7-Jul-86 17:51:18 EDT Article-I.D.: mitre-be.8607072024.AA09444 Posted: Mon Jul 7 17:51:18 1986 Date-Received: Tue, 8-Jul-86 02:56:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 12 Approved: tcp-ip@sri-nic.arpa I appologize for the inconvenience to those of you who may not have gotten the Ulana Specifications yet. I must remove the specifications from a Sun where I was allowed some disk space for the past couple of weeks. The real ulana (a venerable old IS68) is still in the repair shop. I just learned today that I had to move. When I am relocated, I will send out another notice, announcing a new ulana ftp sight. My appologies, bj Pease ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.ardara.219.1%40andrew.cmu.edu] <1986070714072600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leong@ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: IEEE and Ethernet Message-ID: Date: Mon, 7-Jul-86 18:07:26 EDT Article-I.D.: andrew.MS.leong.0.ardara.219.1 Posted: Mon Jul 7 18:07:26 1986 Date-Received: Tue, 8-Jul-86 06:07:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Charles, Our implementation for IP running over the IBM token ring (802.5) uses the 802.2 LLC header. So far we have approximately 100 RT-PC stations running UNIX 4.2 and some 50 IBM PC's running a token ring version of the PCIP code on 4 rings. We have no problems such that some machines on the ring will use the LLC and some won't since only PC's and RT's can be inserted on the ring. We have not done any 802.2 LLC implementation on our Ethernet attached machines since the incompatibility problem you mention will then exist. The router that interconnect the Ethernet to the IBM token ring takes care of the encapsulation and stripping off the LLC header. John Leong leong@andrew.cmu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607080022.AA04435%40ucbvax.Berkeley.EDU] <1986070714190000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mogul@SU-NAVAJO.ARPA (Jeff Mogul) Newsgroups: mod.protocols.tcp-ip Subject: Re: On routing freedom [address masks] Message-ID: <8607080022.AA04435@ucbvax.Berkeley.EDU> Date: Mon, 7-Jul-86 18:19:00 EDT Article-I.D.: ucbvax.8607080022.AA04435 Posted: Mon Jul 7 18:19:00 1986 Date-Received: Tue, 8-Jul-86 06:31:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 69 Approved: tcp-ip@sri-nic.arpa From: mills@dcn6.arpa No gateway implementation known to me (except the fuzzball as of today) supports the ICMP Address Mask messages described in RFC-950. I looked at the 4.3BSD source code; it appears to support the Request message, although I haven't tested an actual running system. I would expect that the Proteon gateway supports this as well, since Noel Chiappa is a partisan. This is the only known case that requires broadcast of an ICMP message, which not only complicates the implementations, but suggests that maybe something is broken in the model. I think what it really means is that it is the first ICMP-level function designed with the knowledge that broadcast is possible. I see nothing wrong with the current model; the original model (that broadcast is not available) was what was broken. Having said that, I must hasten to add that broadcasting should be done only when necessary: when you don't know who to talk to or when (nearly) every host is interested in what you have to say. ARP is a good example; rwho is a rotten example. The real problem is that the ARP/RARP semantics are simply not rich enough and should be expanded to include the mask in the first place. For instance, a RARP reply should include not only the specific host address, but also the address mask associated with its subnet. Also, if promiscuous ARP is used to bypass a specific gateway address, an ARP reply should include the address mask associated with the subnet the address belongs to (if known). The requisite semantics and packet formats might not be hard to provide, since ARP and RARP are quite generic. While adding the subnet mask, the type-of-service mask should also be added. The ICMP Address Mask messages should be junked. This would be a nice optimization of RARP+Address Mask, but it's not a replacement. RARP is part of the ethernet layer (well, the data link layer, but it's only available on ethernets now) but the Address Mask request is important to the IP layer itself. I don't think that, as a general policy, the ICMP Address Mask function should be removed and pushed into RARP. In your environment [which I would attack on aesthetic grounds as a perversion of what is meant by a "local area network", but I'll grant that while it is ugly it is not likely to go away], "piggybacking" extra info on the RARP reply might be a good idea, avoiding the ICMP broadcast unless something goes wrong. However, this would require modifying RARP. Anyway, you don't have to modify the RARP protocol to avoid doing the second broadcast. If we assume that a host which responds to an RARP can be trusted to know the correct mask (an assumption you already have made) then once you get an RARP response, you know the address of a host to which you can send a unicast ICMP Address Mask message. By the way, I don't understand this sentence: Also, if promiscuous ARP is used to bypass a specific gateway address, an ARP reply should include the address mask associated with the subnet the address belongs to (if known). If "promiscuous ARP" means "gateway responds to ARP on behalf of a foreign host" [commonly known as "the ARP kludge"] and "the address" is the target IP address, then I fail to see what is the use to the requesting host of the subnet mask for a non-local wire. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.ardara.219.6%40andrew.cmu.edu] <1986070715471400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leong@ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: Re: IEEE 802 and ISO Message-ID: Date: Mon, 7-Jul-86 19:47:14 EDT Article-I.D.: andrew.MS.leong.0.ardara.219.6 Posted: Mon Jul 7 19:47:14 1986 Date-Received: Tue, 8-Jul-86 06:33:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa re : Flaming about Standard Organisations While I was working for Philips (a large Dutch multi-national), I have actively particpated in various standard organisations such as CCITT, EMAC and IEEE. The problem was (and probably still is) that there has been virtually no representative from the IP world on any of those organisations. It is my contention that particpation in the important standard setting bodies is important so as to influence what is being developed as well as being aware of what is going on. However, participation can be very expensive both in term time and money. (I can remembered a series of working group meeting being held in Tokyo, Berlin, Vienna and Zurich : all before the introduction of frequent flyer programs!!!). As a result, only very large companies and government organisations has the resource to participate. I think it is very appropriate for DARPA to fund for the representation of the IP world and make sure that ideas developed here are heard. Otherwise, we will continue having to figure out how to adapt to other people's invention which will most likely to be incompactible and may well be inferior to what we have been doing. Leong ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607080340.AA03294%40monet.Berkeley.EDU] <1986070719405300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: eric@MONET.BERKELEY.EDU (Eric Allman) Newsgroups: mod.protocols.tcp-ip Subject: Re: failed mail from DCP Message-ID: <8607080340.AA03294@monet.Berkeley.EDU> Date: Mon, 7-Jul-86 23:40:53 EDT Article-I.D.: monet.8607080340.AA03294 Posted: Mon Jul 7 23:40:53 1986 Date-Received: Tue, 8-Jul-86 06:50:08 EDT References: <860630094220.1.JOSEPH@HARLEM.SCRC.Symbolics.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa Re: > Date: Mon, 30 Jun 86 09:42 EDT > From: Joseph R Goldstone > Subject: failed mail from DCP > .... > Someone at a 4.2bsd site told me this "enforcement" took the form of many, > many sendmail processes going into hard loops, pushing the load average up > around 13 and chewing up more than 90% of the machine. The loopy processes > have to be shot. He wasn't happy about it. > - -- joseph I checked this on sendmail, and can't seem to get it to take offense to spaces after a "MAIL From:" command. If this is true, I would like to see some more details. eric ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12220931437.10.JNC%40XX.LCS.MIT.EDU] <1986070719412300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: IEEE and Ethernet Message-ID: <12220931437.10.JNC@XX.LCS.MIT.EDU> Date: Mon, 7-Jul-86 23:41:23 EDT Article-I.D.: XX.12220931437.10.JNC Posted: Mon Jul 7 23:41:23 1986 Date-Received: Tue, 8-Jul-86 06:49:38 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa How do you do address translation? I.e. where does the code that creates the LLC header get the 48 bit address from to go with a 32 bit IP address? Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607081413.AA14152%40ucbvax.Berkeley.EDU] <1986070805302100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mckenzie@J.BBN.COM (Alex McKenzie) Newsgroups: mod.protocols.tcp-ip Subject: DoD Representation at ISO Message-ID: <8607081413.AA14152@ucbvax.Berkeley.EDU> Date: Tue, 8-Jul-86 09:30:21 EDT Article-I.D.: ucbvax.8607081413.AA14152 Posted: Tue Jul 8 09:30:21 1986 Date-Received: Tue, 8-Jul-86 23:39:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 40 Approved: tcp-ip@sri-nic.arpa It might be worth commenting briefly on the amount of representation which the DoD protocols HAVE had in ISO. Attendance at ISO meetings is restricted to individuals who represent recognized NATIONAL standards organizations. For most of the OSI work that means ANSI in the US, and as an ANSI representative in an ISO meeting it is your job to support the ANSI view; if you push some other view you will not be acredited to attend the next ISO meeting. As in any other social/technical/political arena, one has to establish a reputation of credibility before other members of the group will begin to pay serious attention to you. Thus to be effective in ISO, one needs to build up credibility in ANSI, convince ANSI to adopt your view as the US position, start going to ISO meetings to build up credibility, and finally convince ISO to adopt the US position. Within ANSI there are all sorts of competing pressures, and similarly within ISO there are all sorts of national positions to be resolved. The US National Bureau of Standards (within Dept of Commerce) has had a long-standing program of attempting to influence the adoption of US national (ANSI) and international (ISO) standards for data communications which meet the needs of the US government. A major factor in the definition of "the needs of the US government" has been the DoD protocol suite. The NBS sent representatives to almost every relevant ANSI and ISO meeting for about 5 years to push the DoD TCP and IP protocols and, in my opinion, performed a great national service in doing so. In spite of the constant stream of complaints in this mailing list about how the job done was imperfect (and it certainly was imperfect), I think that the ISO has adopted network and transport protocols which the TCP/IP community can live (and prosper) with if it wants to. As far as the IEEE 802 issue is concerned, there was far less DoD input into this via NBS, on the grounds that TCP/IP is supposed to provide for interconnection of packet networks built according to arbitrary standards, and therefore if one has TCP/IP or TP4/Connectionless-network one doesn't need to constrain the design of individual subnets (like 802.3) to any great degree. Disclaimer: As program manager of a BBN contract effort for NBS to support the development of protocol standards, I was heavily involved in the work described above and may therefore view its results more favorably than others who have viewed the activity from the sidelines. Alex McKenzie BBN ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.leong.248.0%40andrew.cmu.edu] <1986070814403600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong@ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: IEEE and Ethernet Message-ID: Date: Tue, 8-Jul-86 18:40:36 EDT Article-I.D.: andrew.MS.leong.0.leong.248.0 Posted: Tue Jul 8 18:40:36 1986 Date-Received: Wed, 9-Jul-86 03:46:16 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Noel, Re : >> How do you do address translation? >> I.e. where does the code that creates the LLC header >> get the 48 bit address from to go with a 32 bit IP address? The LLC header is encapsulated by the MAC layer (or "hardware" layer) header. The LLC header consists of a one-byte DSAP, one byte SSAP and a one byte control field. There is no 48 bit address in the LLC header. [The DSAP and SSAP has the value of 6 for the IP/TCP family of protocol. The control field has the value of 3 for UI : Un-numbered I-frame.] Encapsulated inside the LLC header is the IP or ARP packet. May be the 48 bit address you refered to is the 48 bit address in the MAC (802.3 Ethernet or 802.5 Token Ring) layer header. In which case, the IP (32 bits) to MAC (48 bits) layer address mapping is done by ARP is per Plummer's algorithm. Leong ----MESSAGE-END---- ----MESSAGE-BEGIN---- [REINER.2730235735%40November] <1986070816485600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: REINER%November%ti-csl.CSNET@CSNET-RELAY.ARPA Newsgroups: mod.protocols.tcp-ip Subject: RFC950 Message-ID: Date: Tue, 8-Jul-86 20:48:56 EDT Article-I.D.: November.REINER.2730235735 Posted: Tue Jul 8 20:48:56 1986 Date-Received: Wed, 9-Jul-86 03:46:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa SUBJECT: QUESTION CONCERNING RFC950 RFC950 specifies two new ICMP message types, Address Mask Request and Address Mask Reply. They are used to find the address mask for a given subnet. They specify the types, AM1 to represent an address mask request message and AM2 to represent an address mask reply message. Question: What numerical values are associated with AM1 and AM2 for the type field in an ICMP header? Within RFC792-Internet Control Message Protocol, there is a list of message types used by ICMP, none of which reflect the type field representation of AM1 or AM2. Lisa Reiner ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986070904234500> Received: from B.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 9 Jul 86 11:28:58-PDT Date: 9 Jul 1986 11:23:45 PDT From: POSTEL@B.ISI.EDU Subject: re: RFC-950 To: TCP-IP@SRI-NIC.ARPA Lisa Reiner: See the last two lines of RFC-950, that is Appendix IV on page 17. AM1 = 17 and AM2 = 18. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607091545.AA07954%40hydra.ARPA] <1986070907453000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leiner@RIACS.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: IEEE 802 and ISO Message-ID: <8607091545.AA07954@hydra.ARPA> Date: Wed, 9-Jul-86 11:45:30 EDT Article-I.D.: hydra.8607091545.AA07954 Posted: Wed Jul 9 11:45:30 1986 Date-Received: Thu, 10-Jul-86 05:06:34 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa John, I agree with you that it is important to have representation from the IP world on the standard setting bodies. The IAB has been wrestling with the problem, with no satisfactory solution to date. There is a view that says that DARPA should fund such representation. There is also the opposing view. Both have strong arguments in their favor. (The opposing view doesn't say there should not be representation; only that it is not appropriate for DARPA to fund it) Keep tuned. In the meantime, voluntary participation by IP knowledgable people on standards bodies is certainly encouraged. Also, places like DCA and NBS are doing their best, again with limited resources. Barry ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607091727.AA02374%40ucbvax.Berkeley.EDU] <1986070907550400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@D.ISI.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: RFC950 Message-ID: <8607091727.AA02374@ucbvax.Berkeley.EDU> Date: Wed, 9-Jul-86 11:55:04 EDT Article-I.D.: ucbvax.8607091727.AA02374 Posted: Wed Jul 9 11:55:04 1986 Date-Received: Thu, 10-Jul-86 20:55:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa In response to the message sent 8-Jul-86 17:48:56 from REINER%November%ti-csl.csnet@CSNET-RELAY.ARPA Lisa, See Appendix IV at the end of RFC-950. The assigned numbers are AM1 = 17, AM2 = 18. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.leong.248.5%40andrew.cmu.edu] <1986070908330500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leong@ANDREW.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO Message-ID: Date: Wed, 9-Jul-86 12:33:05 EDT Article-I.D.: andrew.MS.leong.0.leong.248.5 Posted: Wed Jul 9 12:33:05 1986 Date-Received: Thu, 10-Jul-86 21:55:57 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa While it is true that ISO meetings are restricted to individuals who represent recognized NATIONAL standards organizations, it is interesting to note that ISO standards have been heavily influenced by other standard organisations with much more open membership such as IEEE, CCITT and EMAC (which has strong US representations with names such as IBM, DEC, Honeywell etc.) In most cases, ISO simply rubber stamp proposals from such bodies. The IEEE802 standards are a case in point. Other examples are the great similarlity between the Transport Protocol, ECMA-72 and the ISO/DP8072/3; the Office Document Architecture, ECMA-101 and ISO DP8613. It is nice to know that BBN is contracted by NBS (and, hence, ANSI - a voting member of ISO) to support the development of protocol standards since it is also heavily involved with the ARPANET activities. However, it is not clear how much BBN is influencing the NBS standards using experience learned from the ARPANET world. Furthermore, judging by the furor with TP-4, it definitely is not doing a good job keeping the ARPNET people informed on the development of those standards. (It is interesting to note that BBN has prepared for NBS a set of very detail and excellent specifications for the Transport Protocol way back in 1980/1 which is practically the same as the ISO standard). While it is probably not part of their job to keep people informed, it does have the disadvantage that it will not get input from people who is supposed to be actively involved and sometimes knowledgable in networking. In view of the fact that every one seems to be climbing on the standard bandwagon this days, it is my contention that the people of the TCP/IP world should be kept informed of the activites of the standard setting bodies as well as participating directly or indirectly. Otherwise, we will only have ourselves to blame if the world comes up standards which is both strange and may be a little bit stupid. (Of course we can always ignore the rest of the world - until funding runs out). Standards that have come up so far that influence our work to different degree without any significant inputs from the ARPNET world are : X25, Tranpsort Protocol, Session Protocol, IEEE standards, X400. Potentially interesting protocols being developed at this momement : Internet protocol, more on X400, Office Document Architecture, File Transfer Access and Management protocol. Leong ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607092211.AA07188%40ucbvax.Berkeley.EDU] <1986070910234500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: POSTEL@B.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: re: RFC-950 Message-ID: <8607092211.AA07188@ucbvax.Berkeley.EDU> Date: Wed, 9-Jul-86 14:23:45 EDT Article-I.D.: ucbvax.8607092211.AA07188 Posted: Wed Jul 9 14:23:45 1986 Date-Received: Thu, 10-Jul-86 22:29:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Lisa Reiner: See the last two lines of RFC-950, that is Appendix IV on page 17. AM1 = 17 and AM2 = 18. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607091826.AA12301%40braden.isi.edu] <1986070910261500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@VENERA.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Installing tn3270 Message-ID: <8607091826.AA12301@braden.isi.edu> Date: Wed, 9-Jul-86 14:26:15 EDT Article-I.D.: braden.8607091826.AA12301 Posted: Wed Jul 9 14:26:15 1986 Date-Received: Thu, 10-Jul-86 22:16:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 73 Approved: tcp-ip@sri-nic.arpa I have recently installed the Berkeley version of tn3270 on my Sun 3 work station. I used the public tar file tn3270tar, mentioned in Greg Minshall's message copied to tcp-ip on June 6; the main program file is dated 5/13/86. The Sun environment caused some difficulties; for example, you must give tn3270 a Sun window of exactly the size of the emulated 3278 screen (in my case, 43*80; see below), or it just dies due to bad return code form curses. It also took me awhile to work out a sensible mapping of the essential 3278 keys onto the Sun 3 keyboard, avoiding the keys that Suntools wants to keep to itself. In addition, there were some significant problems in tn3270 itself, when used to access both the Wisconsin VM code and the UCLA MVS code. These were as follows: 1. It has been recommended that the terminal type be updated to a 3278-2, which has 24 lines of 80 characters. However, both VM and MVS are prepared to handle the more modern screen size of 43*80, so if you have a competant terminal (like a Sun), I strongly suggest you use the terminal type 3278-4. In this case, it is necessary to update the defined constant NUMBERLINES in 3270.h to be 43. [tn3270 really should take the terminal type (or at least a Boolean selecting long/short screens) from a parameter, and NUMBERLINES should be a variable set as a result.] 2. tn3270 does not support the Erase Write Alternate command, which both VM and MVS send. Its effect should be exactly like Erase Write, but it needs to be included in the case statement in datastream.c, or it defaults to Write; the result is a failure to clear the screen sometimes, which is BAD. 3. tn3270 supports only the non-SNA commands, not the SNA commands. Here's a summary of the relevant command codes: command non-SNA SNA ------------------------------------------ Erase/Write x'05' x'f5' Erase/Write alternate x'0d' x'7e' Write x'01' x'f1' Erase All unprotected x'0f' x'6f' Read Buffer x'02' x'f2' Read Modified x'06' x'f6' It happens that VM and MVS use the non-SNA and SNA commands, respectively, as most appropriate to their system environment. I believe that IBM FSD intends to standardize on the SNA flavor, and update the VM code to send it. In any case, any reasonable 3278 emulator should accept both sets (I think the VM and MVS User Telnets do so). 4. tn3270 does not properly return to NVT mode when the server negotiates back to NVT mode (although the VM code doesn't do this, the MVS code does). 5. tn3270, when in NVT mode, carries over the egregious bug from the Berkeley telnet program: in local echo, it send end-of-line as LF instead of the CR LF dictated by the TELNET protocol spec. Why do we have to put up with this petty protocol anarchism? Of these problems, 1-3 are the most serious and fortunately are quite trivial to fix. Upon request, I will send the updates I used. ________ Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607092318.AA08379%40ucbvax.Berkeley.EDU] <1986070910431300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mckenzie@J.BBN.COM (Alex McKenzie) Newsgroups: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO Message-ID: <8607092318.AA08379@ucbvax.Berkeley.EDU> Date: Wed, 9-Jul-86 14:43:13 EDT Article-I.D.: ucbvax.8607092318.AA08379 Posted: Wed Jul 9 14:43:13 1986 Date-Received: Thu, 10-Jul-86 22:57:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa John, 1) It is not my experience that ISO is in the habit of "rubber stamping" standards developed by other groups. The ECMA proposals for Transport were extensively modified by input from other groups, ESPECIALLY NBS in the Class 4 portion, following the original ECMA submission in about 1980. I agree that IEEE 802 may be rubber-stamped. I think the others you mentioned have undergone change and evolution in ISO after initial submission by the other groups, although I'm not intimately familiar with all of them. BBN has not been under contract from NBS for participation in the standards process for about 1.5 years (except Virtual Terminal work, which is also ended, but more recently) due, as I understand it, to NBS budget constraints. This is apparently one of those areas where the current administration believes private industry will do an adequate job without government support. NBS has repeatedly insisted on the sole right to distribute documentation prepared by BBN under NBS contract. We tried, without success, to change this several times, since our output was text files stored on ARPANET-accessible computers. BBN has, at least sporadically, tried to help inform the ARPANET community. In particular, I point with pride to the fact that we manually input the entire text of substantial ISO documents to make them available as RFCs (892,905,926, 941). Of course, one can always do more. In my opinion you are simply wrong when you say that the ISO Transport protocol was developed "without any significant inputs from the ARPNET world". ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986070910431301> Received: from J.BBN.COM by SRI-NIC.ARPA with TCP; Wed 9 Jul 86 11:47:36-PDT Date: Wed, 9 Jul 86 14:43:13 EDT From: Alex McKenzie To: John Leong cc: tcp-ip@sri-nic.ARPA Subject: Re: DoD Representation at ISO John, 1) It is not my experience that ISO is in the habit of "rubber stamping" standards developed by other groups. The ECMA proposals for Transport were extensively modified by input from other groups, ESPECIALLY NBS in the Class 4 portion, following the original ECMA submission in about 1980. I agree that IEEE 802 may be rubber-stamped. I think the others you mentioned have undergone change and evolution in ISO after initial submission by the other groups, although I'm not intimately familiar with all of them. BBN has not been under contract from NBS for participation in the standards process for about 1.5 years (except Virtual Terminal work, which is also ended, but more recently) due, as I understand it, to NBS budget constraints. This is apparently one of those areas where the current administration believes private industry will do an adequate job without government support. NBS has repeatedly insisted on the sole right to distribute documentation prepared by BBN under NBS contract. We tried, without success, to change this several times, since our output was text files stored on ARPANET-accessible computers. BBN has, at least sporadically, tried to help inform the ARPANET community. In particular, I point with pride to the fact that we manually input the entire text of substantial ISO documents to make them available as RFCs (892,905,926, 941). Of course, one can always do more. In my opinion you are simply wrong when you say that the ISO Transport protocol was developed "without any significant inputs from the ARPNET world". ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.BBN.COM%5D.9-Jul-86.16:28:28.DDEUTSCH] <1986070912280000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: DDEUTSCH@A.BBN.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO Message-ID: <[A.BBN.COM].9-Jul-86.16:28:28.DDEUTSCH> Date: Wed, 9-Jul-86 16:28:00 EDT Article-I.D.: <[A.BBN.COM].9-Jul-86.16:28:28.DDEUTSCH> Posted: Wed Jul 9 16:28:00 1986 Date-Received: Thu, 10-Jul-86 22:58:41 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa I must disagree when you mention X.400 as a standard that was developed "without any significant inputs from the ARPANET world." X.400 had its inception in IFIP 6.5, which was (and still is) open to all interested parties and has had a good number of members from the ARPAnet community. The ARPAnet experience with electronic mail was extremely important when the CCITT began to build upon the IFIP work. The details are different, but many of the basic ideas were carried through. Yes, X.400 doesn't use RFC 822 to represent message. Yes, it uses a different form of addressing. But the underlying structure of headers and text, and the definitions of the message headers themselves, draws heavily upon ARPAnet experience. Likewise, the P1 protocol was designed with SMTP and the old MAIL option to FTP in mind. (I can think of at least four members of the American delegation who were quite familiar with ARPAnet mail protocols. In fact, at least three of us had been involved in the development and/or implementation of ARPAnet mail and other protocols.) If it weren't for the wide-spread success and implementation of ARPAnet-style mail, there probably wouldn't be an X.400 series at all. We'd all be contemplating teletex as the ultimate in electronic mail standards. I cannot claim to be unbiased in this discussion. I, too, worked on commercial standards (including X.400) under NBS funding to BBN. Feel free to factor that into your reading of this message! Cheers, Debbie Deutsch ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.leong.147.0%40andrew.cmu.edu] <1986070914301900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong@ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP and Internation standard Message-ID: Date: Wed, 9-Jul-86 18:30:19 EDT Article-I.D.: andrew.MS.leong.0.leong.147.0 Posted: Wed Jul 9 18:30:19 1986 Date-Received: Thu, 10-Jul-86 22:59:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa The comments from Debbie Deutsch on X400 and Alex Mckenzie on the TP-4 (both of BBN) are correct and that input from ARPANET experience have indeed been used to influence standards to different degree in those instances. (More on X400 than TP-4). Still, in view of the fact that the standard bodies are now moving quite aggressively forward in the past few years (which I must say is quite atypical), it is important that the ARPNET community to be aware of what is going on throughout the development stage of those standards. Otherwise, we will get yet more chances to gripe about having to convert to standards which we know little about until they are already cast in concrete with no opportunity to comment. John Leong P.S. : It may be a good idea for DCA or DoD to fund BBN for standard tracking and participation as part of the ongoing TCP-IP protocol evolution and development particularly since there was some stated intent of "following international standard" at some future date. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986070917010000> Received: from WISCVM.ARPA by SRI-NIC.ARPA with TCP; Wed 9 Jul 86 20:12:05-PDT Received: from (MAILER)UIUCVMD.BITNET by WISCVM.ARPA on 07/09/86 at 22:11:52 CDT Received: by UIUCVMD (Mailer X1.23) id 5804; Wed, 09 Jul 86 22:05:53 CDT Date: Wed, 9 Jul 1986 22:01 CDT From: Phil Howard Subject: "restricted standards" To: TCP/IP Group , MAIL working group list Is there anyone who agrees with me that standards that are expected to be universally adopted should have unrestricted distribution? I refer to ISO X.400 and probably other ISO "standards". I'm not against recovering costs of distribution; I'm against restricting the distribution to a sole agent. X.400 issues came up on both of these groups at the same time. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607100412.AA11707%40ucbvax.Berkeley.EDU] <1986070919010000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: PHIL@UIUCVMD.BITNET (Phil Howard) Newsgroups: mod.protocols.tcp-ip Subject: "restricted standards" Message-ID: <8607100412.AA11707@ucbvax.Berkeley.EDU> Date: Wed, 9-Jul-86 23:01:00 EDT Article-I.D.: ucbvax.8607100412.AA11707 Posted: Wed Jul 9 23:01:00 1986 Date-Received: Thu, 10-Jul-86 23:02:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Is there anyone who agrees with me that standards that are expected to be universally adopted should have unrestricted distribution? I refer to ISO X.400 and probably other ISO "standards". I'm not against recovering costs of distribution; I'm against restricting the distribution to a sole agent. X.400 issues came up on both of these groups at the same time. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4719.521343946%40nrtc-gremlin.northrop.com] <1986070919142200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mrose@nrtc-gremlin (Marshall Rose) Newsgroups: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO Message-ID: <4719.521343946@nrtc-gremlin.northrop.com> Date: Wed, 9-Jul-86 23:14:22 EDT Article-I.D.: nrtc-gre.4719.521343946 Posted: Wed Jul 9 23:14:22 1986 Date-Received: Thu, 10-Jul-86 23:04:32 EDT References: <[A.BBN.COM].9-Jul-86.16:28:28.DDEUTSCH> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa Appologies in advance for this message which may be interpreted as a flame: Well, to be completely honest, when I first saw the x.400 stuff three years ago, my knee-jerk reaction was "what is this trash, haven't these guys heard of the ARPAnet?" Fortunately, for all involved including myself, I have calmed down quite a bit. IFIP 6.5 may be open to any and all interested parties, but not too many people in the ARPA Internet knew what was going on. If there really were three or four of the ARPA mail experts doing X.400 stuff, in hindsight, they should have gone back to school, since X.400 missed quite a bit of the ARPA mail philosophy. (Appologies in advance to the four people I've just maligned.) For example, the lack of extensibility in the P2 heading part is AMAZING. How could that get left out? I would feel better about the incompatibilities between 822/821 and P2/P1 if the latter were at least a proper superset of the former. But when a bunch of people sat down to spec an ARPA/MHS gateway (chaired by an IFIP WG6.5 subcommittee chair, no less), it became painfully obvious that some things were just plain orthogonal, and anyone with ARPAnet experience must have been gone when the drafting/voting took place. I could start ranting and raving about how the first X.400 implementations I've seen are repeating all the same mistakes we made in the ARPAnet, but you get my bias. For example, because of it's typed-data nature, X.400 makes it harder to mistake a user interface for a user agent, but people are still trying to do this. The whole addressing problem is another nightmare, which I hope someone is going to resolve real soon. Otherwise, we are going to start seeing the X.400 equivalent of %'s in MHS addresses. Except now we can put source routing in names instead of addresses! Now I suppose that all of this is the usual coming up on the power curve, and that eventually we'll start seeing some forward progress instead of sideways progress. I hope. Again, sorry for the flames, /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5292.521356510%40nrtc-gremlin.northrop.com] <1986070923111400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: stef@nrtc-gremlin (Einar Stefferud) Newsgroups: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO Message-ID: <5292.521356510@nrtc-gremlin.northrop.com> Date: Thu, 10-Jul-86 03:11:14 EDT Article-I.D.: nrtc-gre.5292.521356510 Posted: Thu Jul 10 03:11:14 1986 Date-Received: Thu, 10-Jul-86 23:52:39 EDT References: <4719.521343946@nrtc-gremlin.northrop.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 54 Approved: tcp-ip@sri-nic.arpa I think it is important, though flaming is most always more fun, to see if there is a useful middle road through this swamp. Yes, it is a swamp! Debbie is dead right about how we would be looking forward to the glories of TELETEX as the mainstay of International EMail, if it had not been for a small cadre of ARPANAUGHTS who banded together under the IFIP flag to develop the basic UA/MTA Computer Mail Model which is the underpinning of X.400. TELETEX is upscale TELEX, and its view of the world is that of a network of terminals, which put ink on paper according to electric signals that come in over a wire. Its basic concept is that of remote printing. TELETEX is your basic electronic stone and chisel. Interesting, but ... X.400 MHS adopted the ARPANET developed view of Net-Mail, with inter- computer file-file text transfers as its basic mail transfer mechanism. TELETEX and X.400 are basically orthoganal to each other. X.400 has all the right concepts in its foundations, but the architects did not all understand how the parts should be assembled. So, we have headers, but they are not defined to be extensible, yet. We have a hierarchical addressing scheme, but it is tainted with a need for names to be route- dependent. If we are not very very careful, all the ughlyness of our wonderful @%.! source rooted internet routing addresses will reappear in X.400, complete with P2 envolope address munging in the MTA relays. One of the biggest problems I see, in trying to work with the ISO TOP/MAP, et al, communities is to get them to understand that TCP/IP is not the enemy. This is not easy when all I can show them is ranting and raving such as I see here, even from my friends who are working with me in the TOP/MAP ISO community. So, how about lets find a way to get hte ISO documents from the NBS and elsewhere, and make them available on SRI-NIC, after the fashion of RFCs. I bet that if we try to get this stuff and make it available, we can get a better view of what is going on, and find a way to make positive contributions to the future of the coming global internet. Lets face it, the internet is what we should call a MegaTrend (following the naming tradition of John Naisbitt). The Internet is going to happen, and X.400 is going to happen. We are headed for an ISO Sea and an X.400 Sea, and there is no way for any TCP/IP or SNA or DECNET Islands to stop it from happening. So lets get with it and help to make it work for us. My objective is to get the ISO and X.400 stuff to working weel enough that the arguements over TCP/IP and SMTP/822 become simply irrelevant. I cannot think of a better fate for them. Think on it - Are you part of the problem or part of the solution? Best - Stef PS: If you are interested in the "routing information in names" problem, I will be pleased to send along a statement of the problem in X.400 terms. - /S ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071004373300> Received: from NRL-LCP.ARPA by SRI-NIC.ARPA with TCP; Thu 10 Jul 86 11:37:33-PDT Date: Thu 10 Jul 86 11:37:33-PDT From: "Rick Jones" Subject: software... To: "tcp-ip" Reply-To: "Rick Jones" Is there a better alternative to the Wolongong TCP/IP software? Also, how do we sign-up for this list? please direct all replies to scott@nrl-lcp.arpa thank you ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607101453.AA18727%40ucbvax.Berkeley.EDU] <1986071006042500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcs@USNA.ARPA (Terry Slattery) Newsgroups: mod.protocols.tcp-ip Subject: POP for dumb workstations Message-ID: <8607101453.AA18727@ucbvax.Berkeley.EDU> Date: Thu, 10-Jul-86 10:04:25 EDT Article-I.D.: ucbvax.8607101453.AA18727 Posted: Thu Jul 10 10:04:25 1986 Date-Received: Fri, 11-Jul-86 00:39:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Is anyone working on a variation of the Post Office Protocols for workstations which don't have an SMTP delivery mechanism? We're envisioning a protocol where the user runs a mail client process on the workstation. This process communicates with the mail server machine for handling both reading and submitting mail. No SMTP process runs on the workstation. The workstations that we're thinking about are the smaller workstations (SGI Iris, IBM-PC, etc). -tcs Terry Slattery U.S. Naval Academy 301-267-4413 ARPA: tcs@usna.arpa UUCP: decvax!brl-smoke!usna!tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071006042501> Received: from USNA.ARPA by SRI-NIC.ARPA with TCP; Thu 10 Jul 86 07:11:55-PDT Date: Thu, 10 Jul 86 10:04:25 EDT From: Terry Slattery To: tcp-ip@SRI-NIC.ARPA cc: baccala@USNA.ARPA Subject: POP for dumb workstations Is anyone working on a variation of the Post Office Protocols for workstations which don't have an SMTP delivery mechanism? We're envisioning a protocol where the user runs a mail client process on the workstation. This process communicates with the mail server machine for handling both reading and submitting mail. No SMTP process runs on the workstation. The workstations that we're thinking about are the smaller workstations (SGI Iris, IBM-PC, etc). -tcs Terry Slattery U.S. Naval Academy 301-267-4413 ARPA: tcs@usna.arpa UUCP: decvax!brl-smoke!usna!tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6437.521393803%40nrtc-gremlin.northrop.com] <1986071008571500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mrose@nrtc-gremlin (Marshall Rose) Newsgroups: mod.protocols.tcp-ip Subject: Re: POP for dumb workstations Message-ID: <6437.521393803@nrtc-gremlin.northrop.com> Date: Thu, 10-Jul-86 12:57:15 EDT Article-I.D.: nrtc-gre.6437.521393803 Posted: Thu Jul 10 12:57:15 1986 Date-Received: Fri, 11-Jul-86 00:52:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa If your workstations are running UNIX with some sort of TCP/IP support (e.g., native Berkeley UNIX, or AT&T UNIX [s5r2] with an EXOS board), then you can probably use MH to do that. It's got a configuration option that says "post mail with smtp server at ". It also can be configured to use POP as the default when incorporating new mail. For more info, contact Bug-MH@ICS.UCI.EDU. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607101829.AA23175%40ucbvax.Berkeley.EDU] <1986071009294100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jnc@BRUBECK.PROTEON.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Hosts forwarding packets Message-ID: <8607101829.AA23175@ucbvax.Berkeley.EDU> Date: Thu, 10-Jul-86 13:29:41 EDT Article-I.D.: ucbvax.8607101829.AA23175 Posted: Thu Jul 10 13:29:41 1986 Date-Received: Fri, 11-Jul-86 22:47:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jnc@proteon.com Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Yet another network problem (this time at MIT) has been traced to hosts (Symbolics lisp machines) not understanding subnet broadcast packets and forwarding them (and sending ICMP Redirects as well). To repeat: a) under no circumstances should hosts forward packets, and b) when using broadcast, try and use the simplest possible broadcast address (all 1's) to prevent misunderrstanding of whether or not something is a broadcast. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071009294101> Received: from brubeck.proteon.com by SRI-NIC.ARPA with TCP; Thu 10 Jul 86 10:36:47-PDT Date: Thu, 10 Jul 86 13:29:41 EDT From: jnc@brubeck.proteon.com Reply-to: jnc@proteon.com Subject: Hosts forwarding packets To: tcp-ip@nic CC: bug-cgw,bug-lispm@ai.ai.mit.edu,jnc Yet another network problem (this time at MIT) has been traced to hosts (Symbolics lisp machines) not understanding subnet broadcast packets and forwarding them (and sending ICMP Redirects as well). To repeat: a) under no circumstances should hosts forward packets, and b) when using broadcast, try and use the simplest possible broadcast address (all 1's) to prevent misunderrstanding of whether or not something is a broadcast. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12221614541.25.OLE%40SRI-NIC.ARPA] <1986071010134700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: OLE@SRI-NIC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Vendors Guide Update Message-ID: <12221614541.25.OLE@SRI-NIC.ARPA> Date: Thu, 10-Jul-86 14:13:47 EDT Article-I.D.: SRI-NIC.12221614541.25.OLE Posted: Thu Jul 10 14:13:47 1986 Date-Received: Fri, 11-Jul-86 22:48:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Yes, it is that time again. A new hardcopy version of the TCP/IP Implementations and Vendors Guide is being planned for August, and we need to have the information as complete and current as possible. Please take a moment to review the file: [SRI-NIC.ARPA]NETINFO:TCP-IP-IMPLEMENTATIONS.TXT ...and send any corrections or additions to OLE@SRI-NIC.ARPA. For new implementations you may use the blank template found in: [SRI-NIC.ARPA]NETINFO:TCP-TEMPLATE.TXT Thank you for your cooperation, Ole J Jacobsen, DDN Network Information Center PS. Please note that X.25 interfaces are also listed in the guide. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860710153354.9.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986071011330000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: Re: Lisp machines don't receive network level broadcasts right, causing net mayhem Message-ID: <860710153354.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 10-Jul-86 15:33:00 EDT Article-I.D.: FIREBIRD.860710153354.9.DCP Posted: Thu Jul 10 15:33:00 1986 Date-Received: Sun, 20-Jul-86 04:09:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Date: Thu, 10 Jul 86 13:28:47 EDT From: jnc@brubeck.proteon.com Hosts shouldn't be forwarding packets (or sending redirects) anyway. It is a complete bug that the LISP machine are even presuming to do either. I agree there is a bug with broadcast packets. But... if a non-gateway host receives a non-broadcast packet that is not for it, why shouldn't it BOTH forward it and send a redirect? How is the sender to know that it is sending packets to the wrong place? P.s., it looks like your mail sending program didn't tack on @proteon.com to the bug-cgw CC recipient. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.BBN.COM%5D10-Jul-86.15:34:30.DDEUTSCH] <1986071011340000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DDEUTSCH@A.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO Message-ID: <[A.BBN.COM]10-Jul-86.15:34:30.DDEUTSCH> Date: Thu, 10-Jul-86 15:34:00 EDT Article-I.D.: <[A.BBN.COM]10-Jul-86.15:34:30.DDEUTSCH> Posted: Thu Jul 10 15:34:00 1986 Date-Received: Fri, 11-Jul-86 23:03:26 EDT References: <4719.521343946@nrtc-gremlin.northrop.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 81 Approved: tcp-ip@sri-nic.arpa Continuing in the spirit of non-flaming... In 1978, when the IFIP 6.5 effort got going, a good many of the then-active participants in ARPAnet mail knew what was going on. They showed up at the initial meetings and gave papers. Some became involved in IFIP 6.5. Others did not. Maybe the costs and time involved in travelling to meetings had something to do with this. Whatever the cause, my impression at the time was that there was very little interest in this activity among the members of the ARPAnet community. On the other hand, information was available. Otherwise, how did the people at UBC come up with the EAN system so quickly? Writing standards can be very frustrating at times, especially if you have a particular idea of what is technically "right". Being technically "right" is sometimes not sufficient to get your idea adopted. In fact, what is "right" is often a matter of context. What is right in a standard are those technical features that help meet its design goals. The set of design goals that is right for one standard may not be right for another. In this case, the sets of design goals appropriate for ARPAnet and for CCITT mail standards are not identical. In the ARPAnet environment we prize fluidity, the ability of individual implementors to try their own ideas and to experiment over very short time frames. We also like to emphasize generality. In the commercial world, where the introduction of a single version of a product can take a long time and be very costly, it is important to be able to be stable. Every vendor wants to be able to add features, but no vendor wants to be forced to change products once they have been fielded. Product lifecycle costs and compatibility with existing systems are very important to the people who write commercial standards. Extensibility as a design goal is a good example of the differences and similarities between the ARPAnet and commercial worlds. When the authors of RFC 733 (the predecessor to RFC 822) began to work, there was a conscious decision to stay with the general design of RFC 680. They knew that this approach would not easily accomodate multimedia mail. Compatibility with RFC 680 mail systems was a more important consideration than extensibility to multimedia mail. The ARPAnet being a research environment, multimedia mail research could be done using an entirely different representation. In the CCITT, the ability to allow individual people and organizations to define their own message headers was less important than support for media other than text. So the X.400 series makes one set of tradeoffs about extensibility, while RFC 822 and SMTP make another. There really was quite a lot of technical debate at the CCITT X.400 meetings, some of it quite heated, 99.99% of it extremely intelligent. Few organizations are willing to spend the many, many thousands of dollars it takes to send representatives around the world to lots of meetings and then pick people who are ill-informed or stupid. Two of my lasting impressions of that group was how hard everybody worked, and how much everybody involved wanted to come up with a standard that would work. There *was* debate about other mechanisms to support P2 header extensions. The consensus was against them, so they were not adopted. As far as CCITT is concerned, there is extensibility for P2. Remember that X.400 is for the interface of systems at national/administration boundards. What goes on inside a country is not the concern of CCITT. If two countries want to agree to exchange messages with headers that go beyond those defined in P2, they can. That's why there is perDomainBilateralInfo. A single country/administration can decide on a way to support ad hoc extensions to P2 for internal use. That's perfectly okay, as long as those messages don't make it into other countries/administrations. The bottom line is that CCITT has different goals than we have on the ARPAnet, so it is not surprising to me that they came up with a different solutions. It is unfortunate and inconvenient that there isn't an isomorphic mapping between the two sets of specifications. In reality, compatibility with the ARPAnet is not an argument that will win the hearts and minds of many commercial vendors, even those located here in the USA. Incompatibility between X.400 and the ARPAnet is our problem, not theirs. That's just the way things are. Regards, Debbie P.S. I heartily agree with your observations about the MHS addresses. What do you think of the newer work on names and directory services? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071011340001> Received: from A.BBN.COM by SRI-NIC.ARPA with TCP; Thu 10 Jul 86 12:37:18-PDT Date: 10 Jul 1986 15:34-EDT Sender: DDEUTSCH@A.BBN.COM Subject: Re: DoD Representation at ISO From: DDEUTSCH@A.BBN.COM To: mrose@NRTC-GREMLIN.ARPA Cc: DDEUTSCH@A.BBN.COM, leong@ANDREW.CMU.EDU Cc: mckenzie@J.BBN.COM, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.BBN.COM]10-Jul-86 15:34:30.DDEUTSCH> In-Reply-To: <4719.521343946@nrtc-gremlin.northrop.com> Continuing in the spirit of non-flaming... In 1978, when the IFIP 6.5 effort got going, a good many of the then-active participants in ARPAnet mail knew what was going on. They showed up at the initial meetings and gave papers. Some became involved in IFIP 6.5. Others did not. Maybe the costs and time involved in travelling to meetings had something to do with this. Whatever the cause, my impression at the time was that there was very little interest in this activity among the members of the ARPAnet community. On the other hand, information was available. Otherwise, how did the people at UBC come up with the EAN system so quickly? Writing standards can be very frustrating at times, especially if you have a particular idea of what is technically "right". Being technically "right" is sometimes not sufficient to get your idea adopted. In fact, what is "right" is often a matter of context. What is right in a standard are those technical features that help meet its design goals. The set of design goals that is right for one standard may not be right for another. In this case, the sets of design goals appropriate for ARPAnet and for CCITT mail standards are not identical. In the ARPAnet environment we prize fluidity, the ability of individual implementors to try their own ideas and to experiment over very short time frames. We also like to emphasize generality. In the commercial world, where the introduction of a single version of a product can take a long time and be very costly, it is important to be able to be stable. Every vendor wants to be able to add features, but no vendor wants to be forced to change products once they have been fielded. Product lifecycle costs and compatibility with existing systems are very important to the people who write commercial standards. Extensibility as a design goal is a good example of the differences and similarities between the ARPAnet and commercial worlds. When the authors of RFC 733 (the predecessor to RFC 822) began to work, there was a conscious decision to stay with the general design of RFC 680. They knew that this approach would not easily accomodate multimedia mail. Compatibility with RFC 680 mail systems was a more important consideration than extensibility to multimedia mail. The ARPAnet being a research environment, multimedia mail research could be done using an entirely different representation. In the CCITT, the ability to allow individual people and organizations to define their own message headers was less important than support for media other than text. So the X.400 series makes one set of tradeoffs about extensibility, while RFC 822 and SMTP make another. There really was quite a lot of technical debate at the CCITT X.400 meetings, some of it quite heated, 99.99% of it extremely intelligent. Few organizations are willing to spend the many, many thousands of dollars it takes to send representatives around the world to lots of meetings and then pick people who are ill-informed or stupid. Two of my lasting impressions of that group was how hard everybody worked, and how much everybody involved wanted to come up with a standard that would work. There *was* debate about other mechanisms to support P2 header extensions. The consensus was against them, so they were not adopted. As far as CCITT is concerned, there is extensibility for P2. Remember that X.400 is for the interface of systems at national/administration boundards. What goes on inside a country is not the concern of CCITT. If two countries want to agree to exchange messages with headers that go beyond those defined in P2, they can. That's why there is perDomainBilateralInfo. A single country/administration can decide on a way to support ad hoc extensions to P2 for internal use. That's perfectly okay, as long as those messages don't make it into other countries/administrations. The bottom line is that CCITT has different goals than we have on the ARPAnet, so it is not surprising to me that they came up with a different solutions. It is unfortunate and inconvenient that there isn't an isomorphic mapping between the two sets of specifications. In reality, compatibility with the ARPAnet is not an argument that will win the hearts and minds of many commercial vendors, even those located here in the USA. Incompatibility between X.400 and the ARPAnet is our problem, not theirs. That's just the way things are. Regards, Debbie P.S. I heartily agree with your observations about the MHS addresses. What do you think of the newer work on names and directory services? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607102219.AA27366%40ucbvax.Berkeley.EDU] <1986071014211200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jones@nrl-lcp.UUCP Newsgroups: mod.protocols.tcp-ip Subject: software... Message-ID: <8607102219.AA27366@ucbvax.Berkeley.EDU> Date: Thu, 10-Jul-86 18:21:12 EDT Article-I.D.: ucbvax.8607102219.AA27366 Posted: Thu Jul 10 18:21:12 1986 Date-Received: Sat, 12-Jul-86 00:20:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Rick Jones" Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Is there a better alternative to the Wolongong TCP/IP software? Also, how do we sign-up for this list? please direct all replies to scott@nrl-lcp.arpa thank you ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607110353.AA02449%40ucbvax.Berkeley.EDU] <1986071019160600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MILLS@D.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Hosts forwarding packets Message-ID: <8607110353.AA02449@ucbvax.Berkeley.EDU> Date: Thu, 10-Jul-86 23:16:06 EDT Article-I.D.: ucbvax.8607110353.AA02449 Posted: Thu Jul 10 23:16:06 1986 Date-Received: Fri, 11-Jul-86 23:04:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa In response to the message sent Thu, 10 Jul 86 13:29:41 EDT from jnc@proteon.com The NSFnet Backbone fuzzballs and USAN gateway fuzzball have been buggered to discard all broadcasts (as determined by Ethernet destination address) with IP destination address other than that of the expected local subnet. An exception has been made for the routing updates used by the fuzzballs themselves. No ICMP error or redirect messages are sent in response to packets discarded in this way. I regard this as a rather draconian solution, but believe it necessary due to the cavalier disregard of sensible network engineering on the part of several vendors. Having said that, I do believe it prudent to point out in defense of some vendors that the seeds of this problem (but not the excuse) can be traced to Berkeley distributions which were ported to inappropriate environments. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071019160601> Received: from D.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 10 Jul 86 20:17:05-PDT Date: 10 Jul 1986 23:16:06 EDT From: MILLS@D.ISI.EDU Subject: Re: Hosts forwarding packets To: jnc@BRUBECK.PROTEON.COM, tcp-ip@SRI-NIC.ARPA cc: bug-cgw@BRUBECK.PROTEON.COM, bug-lispm@AI.AI.MIT.EDU, cc: MILLS@D.ISI.EDU In response to the message sent Thu, 10 Jul 86 13:29:41 EDT from jnc@proteon.com The NSFnet Backbone fuzzballs and USAN gateway fuzzball have been buggered to discard all broadcasts (as determined by Ethernet destination address) with IP destination address other than that of the expected local subnet. An exception has been made for the routing updates used by the fuzzballs themselves. No ICMP error or redirect messages are sent in response to packets discarded in this way. I regard this as a rather draconian solution, but believe it necessary due to the cavalier disregard of sensible network engineering on the part of several vendors. Having said that, I do believe it prudent to point out in defense of some vendors that the seeds of this problem (but not the excuse) can be traced to Berkeley distributions which were ported to inappropriate environments. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5649.521449635%40nrtc-gremlin.northrop.com] <1986071023291400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@nrtc-gremlin.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO Message-ID: <5649.521449635@nrtc-gremlin.northrop.com> Date: Fri, 11-Jul-86 03:29:14 EDT Article-I.D.: nrtc-gre.5649.521449635 Posted: Fri Jul 11 03:29:14 1986 Date-Received: Fri, 11-Jul-86 23:01:05 EDT References: <[A.BBN.COM]10-Jul-86.15:34:30.DDEUTSCH> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa I am beginning to understand the political realities of standards organizations and committees, although personally, I think it constitutes more of an "explanation" than a "defense". Thanks for letting me know from someone who was there. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607110948.AA09650%40amdahl] <1986071101484000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sjl@amdahl.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ISO Standards and the Internet Message-ID: <8607110948.AA09650@amdahl> Date: Fri, 11-Jul-86 05:48:40 EDT Article-I.D.: amdahl.8607110948.AA09650 Posted: Fri Jul 11 05:48:40 1986 Date-Received: Fri, 11-Jul-86 23:13:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa There has been a fair amount of recent discussion about the effect of ISO and CCITT standards on the Internet. Some of it has been based on informed opinion, some on a lack of knowledge, and some on prejudice. I continue to believe that the Internet community has much to offer those working on OSI. I also believe that the lack of information about the work on OSI is mostly a problem with the mechanisms used to distribute information by the standards bodies (however it is not an easy problem to solve). I will, on an occasional basis, attempt to provide information to this group, but the usual pressures of work prevent me from playing a very active role. Even if more people involved in OSI standards work were able to provide information it is still difficult to see how this would be a substitute for a more predictable and formal way to get information. The following paragraphs describe my current ideas about how we could work towards an answer to this problem. One of the most positive recent developments in OSI is the formation of the Corporation for Open Systems (COS). This non-profit joint venture (funded by industry) might be able to act as an information source about OSI protocols in the same manner as the NIC has provided information about TCP/IP and related protocols. I have some influence in COS as the Amdahl representative, but more voices are needed to explain how important it is to have easy access to current information about OSI. If you really care about the effects of the conversion to OSI protocols, I would strongly recommend that you try and influence COS to provide an ongoing source of OSI information. Some of you could best do this by having your organizations join COS, others could at least write and express interest in having COS act as a source of information about OSI. Those that choose the latter, should try and explain why it is important that COS should provide a free service to non-members (remember that some of us work for organizations that are spending a lot of money to support COS). Stephen J. Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl [ The article above is not an official statement from any organization in the known universe. ] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071102270000> Received: from WISCVM.ARPA by SRI-NIC.ARPA with TCP; Fri 11 Jul 86 08:25:43-PDT Received: from (STGEORGE)UNMB.BITNET by WISCVM.ARPA on 07/11/86 at 10:25:29 CDT Date: 11 JUL 86 09:27-MST From: STGEORGE%UNMB.BITNET@WISCVM.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: BITNET mail follows SEND TCP-IP-IMPLEMENTATIONS.TXT ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D11-Jul-86.07:37:21.CERF] <1986071103370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO Message-ID: <[A.ISI.EDU]11-Jul-86.07:37:21.CERF> Date: Fri, 11-Jul-86 07:37:00 EDT Article-I.D.: <[A.ISI.EDU]11-Jul-86.07:37:21.CERF> Posted: Fri Jul 11 07:37:00 1986 Date-Received: Fri, 11-Jul-86 23:13:29 EDT References: <[A.BBN.COM]10-Jul-86.15:34:30.DDEUTSCH> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa Debbie, I found your message well phrased and persuasive. Having spent the last three years in a commercial environment, I can relate to the difference between CCITT goals and ARPANET/INTERNET. Even CCITT has some narrowness in its thinking relative to the business side of messaging - my impression thus far is that much less progress has been made on the side of interexchange accounting and reconciliation than has been made on the technical side. Another factor which affects CCITT and ISO choices is simply the size of the deliberative body and the mechanisms which are needed to achieve agreement. In the ARPANET world, at least for a part of its history, it was possible to take arbitrary decisions and enforce them because ARPA paid for the work, it was experimental, and the community was not relying on it to make a product which generated profit. In the CCITT/commercial world, the requirements are rather more difficult to meet and there is no arbiter of last resort; only the plenary general assembly meetings and the circulation of draft standards for voting. I think the ARPANET/INTERNET community should be proud that the technology it spawned has captured commercial and international attention - the fact that it emerged somewhat differently from the design we have is almost unavoidable. Just like TCP/TP4 and DOD IP and ISO IP. If there are technical flaws in the international standards which make them unworkable, then we ought to articulate them, but if they can be made to work, then we should do our best to use them so as to achieve compatibility with a much broader segment of the world than just our existing research base. Of course, I am much in favor of pressing on to develop the next set of ideas in the research environment; I just don't expect the research work to emerge in the commercial world in verbatim form (look at X.25 vs ARPANET, for example!). Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071103370001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 11 Jul 86 04:39:55-PDT Date: 11 Jul 1986 07:37-EDT Sender: CERF@A.ISI.EDU Subject: Re: DoD Representation at ISO From: CERF@A.ISI.EDU To: DDEUTSCH@BBNA.ARPA Cc: mrose@NRTC-GREMLIN.ARPA, leong@ANDREW.CMU.EDU Cc: mckenzie@J.BBN.COM, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]11-Jul-86 07:37:21.CERF> In-Reply-To: <[A.BBN.COM]10-Jul-86 15:34:30.DDEUTSCH> Debbie, I found your message well phrased and persuasive. Having spent the last three years in a commercial environment, I can relate to the difference between CCITT goals and ARPANET/INTERNET. Even CCITT has some narrowness in its thinking relative to the business side of messaging - my impression thus far is that much less progress has been made on the side of interexchange accounting and reconciliation than has been made on the technical side. Another factor which affects CCITT and ISO choices is simply the size of the deliberative body and the mechanisms which are needed to achieve agreement. In the ARPANET world, at least for a part of its history, it was possible to take arbitrary decisions and enforce them because ARPA paid for the work, it was experimental, and the community was not relying on it to make a product which generated profit. In the CCITT/commercial world, the requirements are rather more difficult to meet and there is no arbiter of last resort; only the plenary general assembly meetings and the circulation of draft standards for voting. I think the ARPANET/INTERNET community should be proud that the technology it spawned has captured commercial and international attention - the fact that it emerged somewhat differently from the design we have is almost unavoidable. Just like TCP/TP4 and DOD IP and ISO IP. If there are technical flaws in the international standards which make them unworkable, then we ought to articulate them, but if they can be made to work, then we should do our best to use them so as to achieve compatibility with a much broader segment of the world than just our existing research base. Of course, I am much in favor of pressing on to develop the next set of ideas in the research environment; I just don't expect the research work to emerge in the commercial world in verbatim form (look at X.25 vs ARPANET, for example!). Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071106020000> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Fri 11 Jul 86 11:54:54-PDT Received: from northeastern by csnet-relay.csnet id ac20572; 11 Jul 86 14:39 EDT Date: Fri, 11 Jul 86 11:02 EST From: JOHNSON%northeastern.edu@CSNET-RELAY.ARPA To: tcp-ip@SRI-NIC.ARPA, johnson%northeastern.edu@CSNET-RELAY.ARPA Subject: ISO & standards & ... 1) Re: the recent flurry of messages concerning ARPANET info input to ISO. I'm glad this is happening. It would be VERY nice to avoid many of the mistakes that have been seen in ARPALAND. However, we've all been on committees too and know the problems. The NIH syndrome for example. Avoiding that while in an international conference is going to be fun. In our zeal to get the right technical issues resolved let us not forget that ISO has other problems than just technical ones. Like keeping some peace in the international technical community for one. 2) Re: comments awhile back on insufficient vertical information flow from layer to layer. At The last DEC DECUS gathering I had a chance to talk to some of the DECNET wizards. We discussed the problems mentioned here a while back that when solving a congestion problem at one level you might just move it to another layer. We know that TCP/IP has this problem. DECNET has it too as does x.25. Come to that, I've even seen it happen in KERMIT interactions with operating systems. DEC seems to have a good loud voice at ISO according to DEC. I asked if this problem was being addressed at all at ISO. The problem was admitted but no known discussions were taking place at ISO concerning it. The reason I'm mentioning it is because I fought this one myself on an x.25 style system for some time once. Resolving it took more vertical information flow about what was happening at various layers than is permitted by the protocol definition. Everybody must have seen this at one time or another and knows it's a real pain. Does anybody know if this is being dealt with at ISO gatherings? If not then perhaps it should be. 3) Re: netable standards. WONDERFUL idea. I'd also like to see some IEEE standards on the net, especially the 802.x ones. The only Ethernet spec I have came from DEC a few years ago and we know that IEEE changed it's packet format. If these are out there somewhere then would someone please tell me where. If not then maybe they should be. If any of this makes sense, good. If not then just delete it. US mail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 Phone: (617) 437-2335 CSNET: johnson@northeastern.edu ARPANET: johnson%northeastern.edu@relay.cs.net [ "Get your facts first, and then you can distort them as much as you want." Mark Twain A Great Philosopher :-] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607111601.AA01386%40bu-cs.bu.edu] <1986071108010200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: root@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Installing tn3270 Message-ID: <8607111601.AA01386@bu-cs.bu.edu> Date: Fri, 11-Jul-86 12:01:02 EDT Article-I.D.: bu-cs.8607111601.AA01386 Posted: Fri Jul 11 12:01:02 1986 Date-Received: Sat, 12-Jul-86 01:11:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa I know that WiscNet supports RFC930 (Terminal Type Option) which a version of tn3270 from Rice used successfully, it's a nice option in that it's transparent (doesn't interfere with speaking to hosts who don't support/need it), or at least should be (it was with the other tn3270.) I believe it is more like what you want in that I don't believe you can get the 3270 servers to emulate arbitrary screen sizes, just various specific 3278 models (which vary discretely in size.) Which to ask for could be discerned by querying the local screen size (either via the TERMCAP which is active or the ioctl() on later editions, such as SUN or 4.3bsd.) We might put this in one of these days, if we do we'll announce it (or if anyone else does I'd appreciate a copy.) -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607111945.AA14822%40ucbvax.Berkeley.EDU] <1986071108020000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JOHNSON%northeastern.edu@CSNET-RELAY.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ISO & standards & ... Message-ID: <8607111945.AA14822@ucbvax.Berkeley.EDU> Date: Fri, 11-Jul-86 12:02:00 EDT Article-I.D.: ucbvax.8607111945.AA14822 Posted: Fri Jul 11 12:02:00 1986 Date-Received: Sat, 12-Jul-86 01:17:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 57 Approved: tcp-ip@sri-nic.arpa 1) Re: the recent flurry of messages concerning ARPANET info input to ISO. I'm glad this is happening. It would be VERY nice to avoid many of the mistakes that have been seen in ARPALAND. However, we've all been on committees too and know the problems. The NIH syndrome for example. Avoiding that while in an international conference is going to be fun. In our zeal to get the right technical issues resolved let us not forget that ISO has other problems than just technical ones. Like keeping some peace in the international technical community for one. 2) Re: comments awhile back on insufficient vertical information flow from layer to layer. At The last DEC DECUS gathering I had a chance to talk to some of the DECNET wizards. We discussed the problems mentioned here a while back that when solving a congestion problem at one level you might just move it to another layer. We know that TCP/IP has this problem. DECNET has it too as does x.25. Come to that, I've even seen it happen in KERMIT interactions with operating systems. DEC seems to have a good loud voice at ISO according to DEC. I asked if this problem was being addressed at all at ISO. The problem was admitted but no known discussions were taking place at ISO concerning it. The reason I'm mentioning it is because I fought this one myself on an x.25 style system for some time once. Resolving it took more vertical information flow about what was happening at various layers than is permitted by the protocol definition. Everybody must have seen this at one time or another and knows it's a real pain. Does anybody know if this is being dealt with at ISO gatherings? If not then perhaps it should be. 3) Re: netable standards. WONDERFUL idea. I'd also like to see some IEEE standards on the net, especially the 802.x ones. The only Ethernet spec I have came from DEC a few years ago and we know that IEEE changed it's packet format. If these are out there somewhere then would someone please tell me where. If not then maybe they should be. If any of this makes sense, good. If not then just delete it. US mail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 Phone: (617) 437-2335 CSNET: johnson@northeastern.edu ARPANET: johnson%northeastern.edu@relay.cs.net [ "Get your facts first, and then you can distort them as much as you want." Mark Twain A Great Philosopher :-] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607111618.AA10694%40ucbvax.Berkeley.EDU] <1986071108194800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STGEORGE@UNMB.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: BITNET mail follows Message-ID: <8607111618.AA10694@ucbvax.Berkeley.EDU> Date: Fri, 11-Jul-86 12:19:48 EDT Article-I.D.: ucbvax.8607111618.AA10694 Posted: Fri Jul 11 12:19:48 1986 Date-Received: Sat, 12-Jul-86 00:55:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 1 Approved: tcp-ip@sri-nic.arpa SEND TCP-IP-IMPLEMENTATIONS.TXT ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.leong.659.1%40andrew.cmu.edu] <1986071111341700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leong@ANDREW.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ODA - New ISO standard in the working Message-ID: Date: Fri, 11-Jul-86 15:34:17 EDT Article-I.D.: andrew.MS.leong.0.leong.659.1 Posted: Fri Jul 11 15:34:17 1986 Date-Received: Sat, 12-Jul-86 01:19:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 33 Approved: tcp-ip@sri-nic.arpa An interesting standard that has been worked on by various organisations and may affect some of our future activies (particularly in Mail) is called Office Document Architecture. Whereas most of the current document interchange (mail, Teletex) standards deals with character text, ODA tries to address multi-media document. Active particpants to that standard setting acivites include at least Xerox, GM, Boeing, IBM, British Telecom and Northern Telecom. The standard describes 2 modes of document to be transmitted : Processible Form and Formated Form. The latter is indended mainly for dumping into printers. The status of that standard development is relatively advanced. It is currently a ISO DP (Draft Proposal) : DP8613. An attempt has been made last spring to vote it into DIS status (Draft International Standard : from there to International Standard is very much rubber stamping). It failed and more modifications are required. Another attempt is expected for next spring. This standard has reasonably strong and wide based support. It is very similar to the ECMA-101 and CCITT T73 (new Teletex standard for mix mode document) standards. Under ODA are sub-standards being worked on by WG5, covering the content architectures. The content architecture is broken down into 3 sub-components : characters, graphics and bit-map. The character architecture is pretty well defined and is already part of the DP8613 set of standards. The Graphic architecture is almost there. It will be based mainly on an existing draft ISO standard : DIS8632. The Bit map architecture is being worked on heavily at the moment. A DP (draft proposal) will likely to emerge very soon. The above development may have some implication to us if we decide to expand into multi-media mail. John Leong ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071112123500> Received: from B.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 11 Jul 86 19:15:39-PDT Date: 11 Jul 1986 19:12:35 PDT From: POSTEL@B.ISI.EDU Subject: re: POP for Dumb Workstations To: tcp-ip@SRI-NIC.ARPA The reason that POP was designed only to get mail from a big service host to a workstation (and not to deposit messages too), was that the procedure for sending a message from the workstation to a service host would be pretty close to that part od SMTP needed to do the same thing. That is, the SMTP client that is needed in the workstation to deposit messages in a single "big brother" service host is about as simple as a POP client. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12221928442.57.ROMKEY%40XX.LCS.MIT.EDU] <1986071114580600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROMKEY@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: POP for dumb workstations Message-ID: <12221928442.57.ROMKEY@XX.LCS.MIT.EDU> Date: Fri, 11-Jul-86 18:58:06 EDT Article-I.D.: XX.12221928442.57.ROMKEY Posted: Fri Jul 11 18:58:06 1986 Date-Received: Sat, 12-Jul-86 06:20:44 EDT References: <8607101452.AA02008@BORAX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa > No SMTP process runs on the workstation. The workstations that we're > thinking about are the smaller workstations (SGI Iris, IBM-PC, etc). Just a bit of information: FTP Software's latest release has an SMTP server and client for the PC... John Romkey FTP Software, Inc. (617) 868-4878 PO Box 150 UUCP: romkey@mit-vax.UUCP Kendall Square Branch ARPA: romkey@xx.lcs.mit.edu Boston, MA, 02142 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607120315.AA21937%40ucbvax.Berkeley.EDU] <1986071118123500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: POSTEL@B.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: re: POP for Dumb Workstations Message-ID: <8607120315.AA21937@ucbvax.Berkeley.EDU> Date: Fri, 11-Jul-86 22:12:35 EDT Article-I.D.: ucbvax.8607120315.AA21937 Posted: Fri Jul 11 22:12:35 1986 Date-Received: Sat, 12-Jul-86 06:21:13 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa The reason that POP was designed only to get mail from a big service host to a workstation (and not to deposit messages too), was that the procedure for sending a message from the workstation to a service host would be pretty close to that part od SMTP needed to do the same thing. That is, the SMTP client that is needed in the workstation to deposit messages in a single "big brother" service host is about as simple as a POP client. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607120947.AA11480%40sri-spam.arpa] <1986071201474400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gds@SRI-SPAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Am I imagining things? Message-ID: <8607120947.AA11480@sri-spam.arpa> Date: Sat, 12-Jul-86 05:47:44 EDT Article-I.D.: sri-spam.8607120947.AA11480 Posted: Sat Jul 12 05:47:44 1986 Date-Received: Sat, 12-Jul-86 10:29:57 EDT References: <8606302206.AA07389@nrl-aic> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa In article <8606302206.AA07389@nrl-aic>, hemphill@NRL-AIC.ARPA (Gavin Hemphill) writes: > > Sorry about the previous empty message -- fumble fingers strikes again. > > Is it my imagination or are other people experiencing problems as > well. I have noticed lately that I can't FTP files bigger than 20 or 30 KB. > The symptoms are that after 6 or 7 minutes (clock time) the FTP connections > (to wherever from nrl-aic) break, there are no messages or indications from > the remote server just the "ftp>" prompt. Secondary to this when I try to > open a new connection to the same host I'll get the "host unreachable" > message, but if I telnet to any other host -- and from there FTP or telnet > to my original destination I can get through, and after backing out of that > a direct FTP will again get through. Anybody else had similar problems? If > so, any pointers would be appreciated. > G++ Sounds like a couple of problems. The "host unreachable" message could be caused, if you are talking to an imp, by the bug in the imp driver that causes a destination host to be marked down because no packets can be deliv- ered to it. This can be fixed by changing the value of HOSTTIMER in /sys/netimp/if_imp.h from 128 to a smaller number (I used 1 instead of 0 because our imp was crashing and I did not want to deliver packets too quickly to it). The ftp lockup problems sound like the "bad file number" problems we were having a few months ago and a related problem with getting "connection error" messages telnetting from a tiu on a prnet to a vax on the arpanet. I discovered that the connection errors were coming when a gateway from the arpanet to the prnet was having trouble fragmenting a packet of odd byte length > 254. By changing the arpanet mtu on the vax from 982 (act- ually arpanet-pli mtu) to 254 the problem went away. Likewise, many of our bad file number and ftp lockup problems went away when I had the ethernet mtu changed from 1500 to 576. Next time this happens try and figure out to where you were trying to con- nect, and what (if any) gateways you had to go through to get there. If possible, monitor the tcp connection looking for a reset (by doing netstats this will show as a connection going from ESTABLISHED to not showing up at all). If you can turn on tcp debugging, look for a RST packet coming in. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607130015.AA12561%40hoptoad.uucp] <1986071216152800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gnu@hoptoad.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Getting machine readable copies of protocol specs Message-ID: <8607130015.AA12561@hoptoad.uucp> Date: Sat, 12-Jul-86 20:15:28 EDT Article-I.D.: hoptoad.8607130015.AA12561 Posted: Sat Jul 12 20:15:28 1986 Date-Received: Sat, 12-Jul-86 23:22:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Good luck at this. The problem is that the national standards organizations make money by selling copies of these standards. They will not let the technical committees just post them to the net or drop them somewhere for anonymous FTP. This has been an ongoing problem in the ANSI C standardization effort. Happily the IEEE P1003 committee developing a standard for "portable operating systems" (they can't call it Unix(TM)) is in favor of electronic media and has been making drafts and discussion available on the net. I suspect the difference is because the IEEE is answerable to its members, while ANSI is answerable to nobody. PS: I was a member of the ANSI/ISO APL language standards committee and it's true that designing a standard by committee is a different job than building a working system/network/etc. The APL committee took pains to seldom engage in "design", but to just adopt the best and most compatible things from a variety of implementations, inventing new ideas only when required to make everything consistent. Looking from the outside, it seems like the ISO standards folks are building a lot of paper designs that aren't implemented until after the standard is approved. Anyone who ever tried to write a program from its specs, without revising the specs based on what was learned during implementation, will recognize the problems in this. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1986.07.13.09.58.14.milazzo.18630%40titan.rice.edu] <1986071306581300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: milazzo@rice.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Installing tn3270 Message-ID: <1986.07.13.09.58.14.milazzo.18630@titan.rice.edu> Date: Sun, 13-Jul-86 10:58:13 EDT Article-I.D.: titan.1986.07.13.09.58.14.milazzo.18630 Posted: Sun Jul 13 10:58:13 1986 Date-Received: Sun, 13-Jul-86 20:27:22 EDT References: <8607111601.AA01386@bu-cs.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa "I know that WiscNet supports RFC930 (Terminal Type Option) which a version of tn3270 from Rice used successfully" Barry: The 3270 support I wrote for telnet is NOT "a version of tn3270". I wrote the original version of the code long before hearing of tn3270, and possibly before tn3270 was written. I have never seen any version of tn3270. My code examines the user's terminal type and chooses the largest suitable screen size from the following list: 3278-5, 3278-4, 3278-3, 3278-2, 3278-1, 3277-1. If the user's terminal is not a CRT or is too small for any of these terminal types, telnet simply remains in NVT mode. If the user's terminal is an oddly-shaped window, such as on a SUN, telnet uses the appropriate upper left portion of the window. On startup it assumes the default size for the chosen 3270 model, and switches to the alternate size upon receipt of an EWA. My code currently does not support SNA codes, negotiation back to NVT mode, or light pens. It incompletely implements the PT order, and has problems with SYS REQ, though the last may be WISCNET's fault, not mine. SNA codes and negotiation back to NVT mode are trivial fixes. The remainder present varying degrees of difficulty. PEN SELECT would be easy to add, but real light pen support (say with the mouse on a SUN) is fairly difficult. Paul G. Milazzo Dept. of Computer Science Rice University, Houston, TX Domain: milazzo@rice.EDU, milazzo@rice.ARPA BITNET: milazzo@ricenet UUCP: {cbosgd,convex,hp-pcd,sun,waltz}!rice!milazzo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607131657.AA16439%40bu-cs.bu.edu] <1986071308575500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: root@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Installing tn3270 Message-ID: <8607131657.AA16439@bu-cs.bu.edu> Date: Sun, 13-Jul-86 12:57:55 EDT Article-I.D.: bu-cs.8607131657.AA16439 Posted: Sun Jul 13 12:57:55 1986 Date-Received: Sun, 13-Jul-86 20:28:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Apologies for any misunderstanding, I knew that Paul's code was not derivitive of the tn3270 code, I was using the term generically ("a version of tn3270".) I only meant to bring out that not only can various 327x's be supported via subnegotiation, it's even been done (by Paul) and it works. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607140254.AA02835%40phri.uucp] <1986071318542600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: roy@phri.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Fuzzball hosts -- the summary Message-ID: <8607140254.AA02835@phri.uucp> Date: Sun, 13-Jul-86 22:54:26 EDT Article-I.D.: phri.8607140254.AA02835 Posted: Sun Jul 13 22:54:26 1986 Date-Received: Mon, 14-Jul-86 19:54:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: phri!roy@seismo.CSS.GOV (Roy Smith) Distribution: mod Organization: Public Health Research Institute, NYC, NY Lines: 104 Approved: tcp-ip@sri-nic.arpa Some time ago I asked what a fuzzball host was. What follows is a condensation of the responses I got. Thanks to everybody who took the time to reply. Due to my eclectic filing system, this is not in any particular order, chronological or otherwise. ------------ Date: Wed, 18 Jun 86 13:46:28 EDT From: Mike O'Connor Roy, Here is Dave's reply to the forwarding of my description of the origin of the term Fuzzball. [...] BTW, the seismo people use one of Dave's fuzzballs (dcn1) for clock synchronization. Date: 18 Jun 1986 12:52:28 EDT From: MILLS@USC-ISID.ARPA Subject: Re: Official Derivation of the term "Fuzzball" To: oconnor Fuzzball gateways are now in place in the NSF Backbone net, as well as the USAN (university consortium) net, both creatures of NSF. Add NASA, CMU and CNUCE (Italy) to your list. Mention that the fuzz were developed as research tools and intended for application in protocol development, prototype testing and performance evaluation, but have also found temporary application in specialized environments with unusually difficult network routing and management requirements, with the expectation that the vendor community will eventually develop commercial devices that satisfy these requirements. As an aside, the Ethernets of nine universities are now combined (you got it) on the USAN satellite channel. The rwhos are simply glorious. The fuzzies got very clever very quick Dave ---------------- Date: Thu 19 Jun 86 23:49:44-EDT From: "J. Noel Chiappa" Subject: Re: Fuzzball hosts To: phri!roy "Fuzzball" is the name of the software package for the DEC PDP11 written primarily by Dave Mills, MILLS@ISI. It evolved from the DEC RT-11 operating system, but is somewhat more complex by now. It contains a full set of TCP/IP software, and can function as a user or server host and also as a gateway. Noel ---------------- Date: Wed, 18 Jun 86 21:23:23 edt From: Henry Schaffer To: phri!roy Subject: Re: Fuzzball hosts This is a tcp-ip router consisting of code written by Dave Mills?? at U. Md. which runs on a PDP-11. I don't know the origin of the name. ---------------- Date: Thu, 19 Jun 86 19:37:36 CST From: Stan Barber To: roy@phri.uucp Subject: Re: Fuzzball hosts A "fuzzball" is a PDP-11/23 or PDP-11/73 running as a dedicated gateway or providing a network (i.e. internet) service (like the correct time). Their inventor gave them that name for an unknow reason. Currently, the TCP-IP implementation guide sez that fuzzballs are available from M/A-COM Link-a-bit. A friend of mine there never heard of them. Hope this helps. ---------------- Date: Mon, 16 Jun 86 13:29:44 EDT From: Mike O'Connor To: allegra!phri!roy Subject: Re: Fuzzball hosts Roy, In case Dave Mills doesn't answer I'll give you some details. Dave Mills (currently with M/A-Com Linkabit) has a software package (really an Operating System) that emulates Dec's Rt-11 but includes full Arpanet protocol suite. It mostly runs on LSI-11's but some people have a version running on some PDP-11s. A few years back ('80 | '81?) at a meeting at DARPA headquarters, someone used the term "fuzzball" to describe Dave's system. Most of the other people were TOPS-20 users with maybe one UNIX user. While intended as a somewhat derogatory term Dave embraced it and has used it to describe his system ever since. I'm not even sure he remembers the origin. A more detailed description of the Fuzzball system can be found at the NIC in the file describing tcp-ip implementations. There were also a couple of RFC's concerning Dave's system. BTW, the last I heard "Fuzzballs" were going to be used as gateways on the NSFnet. They can be found at the University of Md., University of Michigan, Ford-Aerospace, and quite a few places in Europe. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071406311600> Received: from mitre-bedford.ARPA by SRI-NIC.ARPA with TCP; Mon 14 Jul 86 11:50:57-PDT Full-Name: Pease Message-Id: <8607141851.AA15712@mitre-bedford.ARPA> Organization: The MITRE Corp., Bedford, MA To: tcp-ip@sri-nic.ARPA Subject: ULANA Specifications once again available Date: Mon, 14 Jul 86 14:51:16 -0500 From: bjp@mitre-bedford.ARPA Appologies for the interuption. This letter is in regards to a previous announcement, that due to circumstances beyond my control, I had to move the ftp location for the Ulana Specifications. For the few stagglers who may not have gotten copies yet. A copy is once again available: address: mitre-b-ulana.arpa user: guest password: anonymous pathname: /usr/users/guest/ulana.specs bj Pease ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607141850.AA15697%40mitre-bedford.ARPA] <1986071416463700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bjp@MITRE-BEDFORD.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ULANA Specifications once again available Message-ID: <8607141850.AA15697@mitre-bedford.ARPA> Date: Mon, 14-Jul-86 20:46:37 EDT Article-I.D.: mitre-be.8607141850.AA15697 Posted: Mon Jul 14 20:46:37 1986 Date-Received: Tue, 15-Jul-86 04:48:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 13 Approved: tcp-ip@sri-nic.arpa Appologies for the interuption. This letter is in regards to a previous announcement, that due to circumstances beyond my control, I had to move the ftp location for the Ulana Specifications. For the few stagglers who may not have gotten copies yet. A copy is once again available: address: mitre-b-ulana.arpa user: guest password: anonymous pathname: /usr/users/guest/ulana.specs bj Pease ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607150327.AA07564%40opus] <1986071419273100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: atkins@nbires.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Ways to input your X.400/MOTIS concerns Message-ID: <8607150327.AA07564@opus> Date: Mon, 14-Jul-86 23:27:31 EDT Article-I.D.: opus.8607150327.AA07564 Posted: Mon Jul 14 23:27:31 1986 Date-Received: Wed, 16-Jul-86 03:39:46 EDT References: <8607111945.AA14822@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: nbires!atkins@ucbvax (Brian Atkins) Organization: NBI Inc, Boulder CO Lines: 30 Approved: tcp-ip@sri-nic.arpa The Corporation for Open Systems (COS) is an excellent conduit for input to the international standards bodies, but it is rather expensive. There is the membership fee, plus the additional cost of participation. (It was said by a COS member that COS is not looking for many members of little commitment, but a lesser number of members of great commitment.) There is another, perhaps less direct, input into the ISO/CCITT bodies. NBS has an OSI Workshop which is producing a document entitled "Implementation Agreements Among Implementors of OSI Protocols", which provides a somewhat more precise interpretation of the various OSI standards, namely FTAM and X.400 (in addition to the lower layers). Production of significant portions of this document fall into the hands of SIGs (Special Interest Groups). Participation in these SIGs is "limited" to Implementors, Vendors, and Users of OSI protocols. As you can see, anyone can take part in this process. Many active SIG members are also members of CCITT and ISO, and can thus provide SIG input back into the standards process. NBS out of Gaithersburg, MD can provide information on these workshops and SIG participation. Since these SIGs are populated by people doing the work, many of the real problems are brought out into the open. I can speak from experience, there is a high degree of commitment among the participants (in the X.400 SIG at least). So if you want "be part of the solution" rather than complain about the past, here is an opportunity. Brian Atkins ...{attunix, hao, allegra, ucbvax}!nbires!atkins NBI Inc., P.O. Box 9001, Boulder CO 80301 (303) 444-5710 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607161342.AA26264%40sally.UTEXAS.EDU] <1986071605425200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jsq@SALLY.UTEXAS.EDU (John Quarterman) Newsgroups: mod.protocols.tcp-ip Subject: Re: Getting machine readable copies of protocol specs Message-ID: <8607161342.AA26264@sally.UTEXAS.EDU> Date: Wed, 16-Jul-86 09:42:52 EDT Article-I.D.: sally.8607161342.AA26264 Posted: Wed Jul 16 09:42:52 1986 Date-Received: Sat, 19-Jul-86 01:13:35 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa Brief elaboration on certain points of John Gilmore's message: The X3J11 C Committee (they hate being called ANSI C) has a USENET newsgroup called mod.std.c. It does not appear to be gatewayed to any Internet mailing list. Doubtless the moderator of that newsgroup could elaborate. (The mailing list INFO-C@BRL.ARPA is gatewayed to the different newsgroup net.lang.c.) The IEEE 1003 Portable Operating System for Computer Environments Committee indirectly sponsors the USENET newsgroup mod.std.unix (known in the Internet as the mailing list STD-UNIX@SALLY.UTEXAS.EDU) and many of the committee members read it. I'm the moderator and have in the past made on-line copies of drafts of the standard available by anonymous FTP from sally in cooperation with the rest of the committee. The current document is the published Trial Use Standard and is not available on-line, though future drafts probably will be. Actually, according to IEE what is on-line is something that "represents" the draft: the real draft is the paper copy, which you can also get just by getting on a paper mailing list. For details on access to these committees and standards, see recent articles in mod.std.unix, whose archives may be gotten by anonymous FTP from sally.utexas.edu. The current volume is in /pub/mod.std.unix. PS: IEEE 1003.1 is working on adoption by ISO. We'll see how that affects availability of drafts. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607180413.AA15674%40ucbvax.Berkeley.EDU] <1986071607332700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: eichelbe@NADC.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP for CDC? Message-ID: <8607180413.AA15674@ucbvax.Berkeley.EDU> Date: Wed, 16-Jul-86 11:33:27 EDT Article-I.D.: ucbvax.8607180413.AA15674 Posted: Wed Jul 16 11:33:27 1986 Date-Received: Fri, 18-Jul-86 17:52:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa I have looked at the TCP-IP-IMPLEMEMTATIONS.TXT file available from SRI-NIC, and I have not seen any way for a CDC Cyber computer to hook up and send/receive Internet mail without the aid of a VAX 11/780 as a front-end. Is there anyone out there who *presently* has some TCP/IP implemetation other than those mentioned in the above-stated document? We don't want to have to wait until February, 1987, for CDC to come out with its product. Any info/leads would be greatly appreciated. Please respond directly to me unless what you have to say is of general interest. Thank you, Jon Eichelberger eichelbe@NADC.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071607332701> Received: from nadc by SRI-NIC.ARPA with TCP; Wed 16 Jul 86 08:41:09-PDT Date: 16 Jul 1986 11:33:27-EDT From: eichelbe@NADC To: info-unix@brl, tcp-ip@sri-nic, unix-wizards@brl Subject: TCP/IP for CDC? I have looked at the TCP-IP-IMPLEMEMTATIONS.TXT file available from SRI-NIC, and I have not seen any way for a CDC Cyber computer to hook up and send/receive Internet mail without the aid of a VAX 11/780 as a front-end. Is there anyone out there who *presently* has some TCP/IP implemetation other than those mentioned in the above-stated document? We don't want to have to wait until February, 1987, for CDC to come out with its product. Any info/leads would be greatly appreciated. Please respond directly to me unless what you have to say is of general interest. Thank you, Jon Eichelberger eichelbe@NADC.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071607464400> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Wed 16 Jul 86 13:10:48-PDT To: hwb@GW.UMICH.EDU cc: tcp-ip@sri-nic.ARPA Subject: Re: 127.0.0.1 In-reply-to: Message from hwb@GW.UMICH.EDU posted 16-Jul-86 15:26:26-UT. Date: Wed, 16 Jul 86 16:06:44 -0500 From: Dennis Rockwell Hans, everybody, There's a bug (*not* a feature!) in the 4.2 network code that assigns the source address of a packet to be some single IP interface on that machine (in fact, it binds the local address too early, before the packet or connection has been routed). For incoming TCP connections, there is no problem; the local address is specified by the host that initiates the connection. For outgoing UDP packets, the first interface in the interface list (given by netstat -i) is usually used (although the loopback interface {which uses 127.0.0.1 as its address} is most often the last listed interface). CSNET requires that X25net sites install this fix; during installation and checkout, we most often do not tell our kernel how to reach a site's local network. This causes TCP connections from our new site to the Internet fail while connections from the Internet to the new site work. There are fixes for this available from BRL (at least, that's where I got them). Mike? Are they in anonymous FTP? Dennis Rockwell CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071615262600> Received: from GW.UMICH.EDU by SRI-NIC.ARPA with TCP; Wed 16 Jul 86 08:32:49-PDT Date: 16-Jul-86 15:26:26-UT From: hwb@gw.umich.edu Subject: 127.0.0.1 To: tcp-ip@sri-nic.arpa cc: hwb@GW.UMICH.EDU How come I when I am resolving addresses that I am gettin domain replies with a source address of 127.0.0.1? I think I saw that in response to requests sent to Seismo (10.0.0.25), but may be from other's, too. Telnet to Seimo works fine and does not use 127.0.0.1 on the way back. I just sent domain requests specifically to Seismo, and the problem is easily reproducable. I am posting this to this list since I am not sure whether it was *only* Seismo or others, too. -- Hans-Werner Braun ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607171438.AA12939%40ORNL-MSR.ARPA] <1986071706385900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: yhe@ORNL-MSR.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP on Prime(PRIMOS) Message-ID: <8607171438.AA12939@ORNL-MSR.ARPA> Date: Thu, 17-Jul-86 10:38:59 EDT Article-I.D.: ORNL-MSR.8607171438.AA12939 Posted: Thu Jul 17 10:38:59 1986 Date-Received: Fri, 18-Jul-86 18:32:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Does anyone out there have experience with TCP/IP on a Prime machine using PRIMOS? If so, please mail direct to me a summary of your experience. Young Etheridge, yhe@ornl-msr.arpa Oak Ridge National Laboratory ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071710204800> Received: from ohio-state.ARPA by SRI-NIC.ARPA with TCP; Thu 17 Jul 86 11:56:22-PDT Return-Path: Received: by ohio-state.ARPA (4.12/6.1.OSU-CIS) id AA16808; Thu, 17 Jul 86 14:20:48 edt Date: Thu, 17 Jul 86 14:20:48 edt From: Bob Sutterfield Message-Id: <8607171820.AA16808@ohio-state.ARPA> To: info-vax@sri-kl.arpa, tcp-ip@sri-nic.arpa Subject: Tektronix TCP/IP news? Cc: karl-d@ohio-state.ARPA, mills@ohio-state.ARPA, summers@ohio-state.ARPA A while back, there was some discussion on either info-vax or tcp-ip about a TCP/IP package developed at Tektronix for VMS VAXen. There was even proposed the creation of a discussion list, after which talk on the above lists dropped to nil, as one might expect when traffic moves to a new list. Unfortunately, I can't find out where the tektcp-request address is, to inquire about progress of work on the software. If such a discussion list hasn't been created yet, could someone involved in the work bring me up to date? What various hardware configurations and versions of VMS does Tek-TCP run under? What's involved in getting a copy to test and play with? Is it still `pretty much public-domain' like it was before? What's involved in the `pretty much' part? Thanks for your help. ----- Human: Bob Sutterfield Mail: bob%osuag.uucp@ohio-state.arpa or: bob@ohio-state.arpa or: ...!cbosgd!osu-eddie!osuag!bob or: ...!cbosgd!osu-eddie!bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071714154300> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Thu 17 Jul 86 07:36:58-PDT Date: 17-Jul-86 14:15:43-UT From: mills@dcn6.arpa Subject: TCP/TIME service To: tcp-ip@sri-nic.arpa Folks, The level of TCP/TIME requests directed to our DCnet fuzzballs has escalated to the point of serious intrusion in other services. Our DCN1.ARPA fuzzball, for example, is also our ARPAnet gateway DCN-GATEWAY and well-known as a good source of accurate time. The problem is that the poor horse has only two TCP servers, ordinarily used only for casual snooping and maintenance. A TCP/TIME transaction takes anywhere from eight to 20 seconds, depending on the path and degree of flake involved. At the present volume of requests, it is not unusual for both servers to be occupied, while other requestors are flailing SYNs and congesting the buffer pool. As the longtime browsers of this know, I have invited clockwatchers to use UDP/TIME and NTP/TIME protocols but highly discouraged use of the TCP/TIME protocol. Not only are the former much more accurate, but the latter is very disruptive to our normal operations. Note that Unix daemons for UDP-based time services are readily available. (Eeep - make that UDP/NTP, not NTP/TIME in the above!) Some clockwatchers are using TCP/TIME on DCnet fuzzballs other than DCN1.ARPA. Again, be advised the other critters set their watches from DCN1.ARPA anyway, so there is nothing to be gained except escaping detection in the logs. At the end of the month I will review the situation. If the onslaught persists, I may have to disable the TCP/TIME service, perhaps (following a recent suggestion) including a random offset of amplitude maybe two days. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607180256.AA14746%40ucbvax.Berkeley.EDU] <1986071718575600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hwb@GW.UMICH.EDU Newsgroups: mod.protocols.tcp-ip Subject: 127.0.0.1 Message-ID: <8607180256.AA14746@ucbvax.Berkeley.EDU> Date: Thu, 17-Jul-86 22:57:56 EDT Article-I.D.: ucbvax.8607180256.AA14746 Posted: Thu Jul 17 22:57:56 1986 Date-Received: Fri, 18-Jul-86 06:07:35 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa How come I when I am resolving addresses that I am gettin domain replies with a source address of 127.0.0.1? I think I saw that in response to requests sent to Seismo (10.0.0.25), but may be from other's, too. Telnet to Seimo works fine and does not use 127.0.0.1 on the way back. I just sent domain requests specifically to Seismo, and the problem is easily reproducable. I am posting this to this list since I am not sure whether it was *only* Seismo or others, too. -- Hans-Werner Braun ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607180653.AA18071%40ucbvax.Berkeley.EDU] <1986071722553700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dennis@SH.CS.NET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: 127.0.0.1 Message-ID: <8607180653.AA18071@ucbvax.Berkeley.EDU> Date: Fri, 18-Jul-86 02:55:37 EDT Article-I.D.: ucbvax.8607180653.AA18071 Posted: Fri Jul 18 02:55:37 1986 Date-Received: Fri, 18-Jul-86 17:53:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa Hans, everybody, There's a bug (*not* a feature!) in the 4.2 network code that assigns the source address of a packet to be some single IP interface on that machine (in fact, it binds the local address too early, before the packet or connection has been routed). For incoming TCP connections, there is no problem; the local address is specified by the host that initiates the connection. For outgoing UDP packets, the first interface in the interface list (given by netstat -i) is usually used (although the loopback interface {which uses 127.0.0.1 as its address} is most often the last listed interface). CSNET requires that X25net sites install this fix; during installation and checkout, we most often do not tell our kernel how to reach a site's local network. This causes TCP connections from our new site to the Internet fail while connections from the Internet to the new site work. There are fixes for this available from BRL (at least, that's where I got them). Mike? Are they in anonymous FTP? Dennis Rockwell CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607180816.AA19415%40ucbvax.Berkeley.EDU] <1986071800184300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mills@DCN6.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP/TIME service Message-ID: <8607180816.AA19415@ucbvax.Berkeley.EDU> Date: Fri, 18-Jul-86 04:18:43 EDT Article-I.D.: ucbvax.8607180816.AA19415 Posted: Fri Jul 18 04:18:43 1986 Date-Received: Fri, 18-Jul-86 18:33:11 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa Folks, The level of TCP/TIME requests directed to our DCnet fuzzballs has escalated to the point of serious intrusion in other services. Our DCN1.ARPA fuzzball, for example, is also our ARPAnet gateway DCN-GATEWAY and well-known as a good source of accurate time. The problem is that the poor horse has only two TCP servers, ordinarily used only for casual snooping and maintenance. A TCP/TIME transaction takes anywhere from eight to 20 seconds, depending on the path and degree of flake involved. At the present volume of requests, it is not unusual for both servers to be occupied, while other requestors are flailing SYNs and congesting the buffer pool. As the longtime browsers of this know, I have invited clockwatchers to use UDP/TIME and NTP/TIME protocols but highly discouraged use of the TCP/TIME protocol. Not only are the former much more accurate, but the latter is very disruptive to our normal operations. Note that Unix daemons for UDP-based time services are readily available. (Eeep - make that UDP/NTP, not NTP/TIME in the above!) Some clockwatchers are using TCP/TIME on DCnet fuzzballs other than DCN1.ARPA. Again, be advised the other critters set their watches from DCN1.ARPA anyway, so there is nothing to be gained except escaping detection in the logs. At the end of the month I will review the situation. If the onslaught persists, I may have to disable the TCP/TIME service, perhaps (following a recent suggestion) including a random offset of amplitude maybe two days. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071806132200> Received: from ADA20.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 18 Jul 86 14:30:36-PDT Date: 18 Jul 1986 13:13:22 PDT Subject: VAX IP/TCP From: Douglas M. Olson To: tcp-ip@SRI-NIC.ARPA Preface: This one got longer than I had expected. I'd planned a brief query to INFO-VAX for suggestions: but what this missive is REALLY about is a newcomer to the DDN community trying to bring a new installation aboard the net. It is long. I need some help. If this sort of thing isn't your bag, recommend you skip it! --------- From the outside looking in, I'm having a hard time figuring out what I'm supposed to obtain (hardware and software) to make my VAXCluster able to communicate on the DDN using VAX-based instantiations of TELNET, FTP, and (especially important) SMTP. We have just registered our connection requirement through the normal MAJCOM and ASPO channels. They in turn will get our requirement to DCA who will eventually service us with (we are told informally) a 56KB connection. I'm assuming that this connection will be a conditioned circuit from the nearest node, probably over at AFWL on the other side of Kirtland AFB. I'm also aware that the DCA may elect to install a node here in our facility. I'm being quite free with terms that I don't fully understand. For instance, 'node'. I'm assuming this is (with current technology and given the state of the net) the same thing as a C-30. Which runs some node-control software (versions of which I understand are being upgraded to allow older '1822' implementations to communicate with newer 'x.25' { Basic | Standard } implementations...more terms I don't fully understand). I have policy guidance indicating in typical DoD doublespeak that I Shalt Not Plan to use an 1822 interface, as if I could figure out what I wanted. ACC glossies picked up at DEXPO indicate that the IF-11/HDH "operates in HDH (1822-J) Packet Mode" and "the supported link level protocol is HDLC/LAPB"....does that mean its on the verboten list for being 1822 or is it ok for me to buy? As you can see, from what I can tell of the state of the net world, is that things are in flux. What I can't tell is whether the flux affects the decisions I ought to make right now. Due to the fact that we are completely without the flavor of money that lets us make capital expenditures when we need to, we rely TOTALLY on fallout funds to make such purchases. That is, our only budget is Operations and Maintenance; upgrades depend on our being ready to use other peoples unspent money during a very brief window in August and September. If I don't purchase interfaces next month, then DCA may show up with my connection in May next year and we won't be able to buy the interfaces then, and use the connection, until October! I paint that bleak funding picture to explain WHY I need to answer the interfaces question NOW. Hm; actually, what I want is to use some smart box on the same ethernet that services my VAXCluster. This box needs to support up to 100 simultaneous users who have opened connections from TACs around the country. That '100' is usage projected within 3 years; initially, I can probably get by supporting 50-60 simultaneous. Once into the Cluster, on any machine, a user should be able to use FTP and SMTP to exchange with the rest of the internet, presumably transparently using the same connection route...diagrammed here: VAXCluster---(ethernet)----[Smart Box]===(56KB)===C30.... The reasons I want to do it this way is to avoid either 1) buying a separate interface for every single node on the Cluster or 2) buying one interface for one VAX and then burying that VAX serving i/o to the rest of the cluster... is it a ridiculous concept? Are these ridiculous fears? Given that 'what I want' probably doesn't exist; given that I fully expect to have mangled at least one of these concepts and I HOPE you can understand anyway; given that what I'm trying to do is comply with directives to move all long-haul data communication requirements onto the DDN, and my users are scattered from San Diego to West Palm Beach to Boston to Seattle; I have several pleas to make. Simple ones up front: -anybody else already done this? how? are you using x.25 or 1822 interfaces (or is that even a valid question?) -anybody so inclined, straighten out whichever concepts I mangled; -if I belong in another forum, please point; I've been looking for months. More involved issues: Other approaches: We have 3 Ethernet Terminal Servers (each w/32 ports) on the ether now. They support dial-in modems and a few local hardwires. Is there a device which provides a sort of reverse TAC facility? I believe it may be a device I have heard called a PAD (for Packet Assembler/ Disassembler). If I had numerous terminal ports coming in off the C30 via such a device I could connect each port to the Ethernet Terminal Servers over which we have software configuration control. This solves my WORST problem of bringing my remote users in. I could probably then accomodate putting a single interface for FTP and SMTP and outgoing TELNET onto one VAX in the Cluster. Can anyone address whether or not my understanding of a 'PAD' (or whatever its called) is realistic? Is this a reasonable model? Here are three DEC part numbers for "commercial" (vice educational) TCP/IP networking packages; I understand DEC offers these products through a licensing arrangement with The Wollongong Group. QAX74-CM VAX IP/TCP VMS (supports DEUNA and DMR-11 interfaces) QAXA9-CM VAX IP/TCP DDN (supports DEUNA and ACC's IF-11/HDH) QAXX1-C3 IP/TCP MicroVMS (supports DEQNA) (Just to save anyone the hassle of trying to find the "educational" part numbers, here they are: QAX75-CM VAX IP/TCP VMS and QAXX2-C3 IP/TCP MicroVMS...) Are these the best VMS products available? Will any of them support the [Smart Box] prayer I outlined above? Could a MicroVAX II with the QAXX1-C3 possibly be the Smart Box? Could it support 50-100 users, or would I need three (or 'n', tell me your guess at n) of them? If I HAD three of them, how many can be supported by a single C30? If, above, when I asked if my description of a [Smart Box] was a ridiculous concept, you said to yourself, 'yes, ridiculous; he should just use the blotzo' whats your blotzo? I appreciate your patience. I've been digging since February when Bob Tinker from the David Taylor Naval Ship R&D Center asked about ethernet-DDN gateways. As of late April, he privately expressed interest in new technology under development, upon which a product announcement was expected late this year. I don't know if I can wait; I hope you can tell from the tone of this that I have several degrees of uncertainty about our approach. We're ignorant and need help. From the real-(ignorant)-world of real requirements for day-to-day long-haul data-communications, I'm sayin that we're mighty short on solid information. Comments on the above gratefully appreciated. Lt Doug Olson, USAF Air Force Contract Management Division Future Information Systems Program Manager ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607181451.AA03700%40seismo.CSS.GOV] <1986071806512500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: mod.protocols.tcp-ip Subject: Re: 127.0.0.1 Message-ID: <8607181451.AA03700@seismo.CSS.GOV> Date: Fri, 18-Jul-86 10:51:25 EDT Article-I.D.: seismo.8607181451.AA03700 Posted: Fri Jul 18 10:51:25 1986 Date-Received: Sat, 19-Jul-86 02:31:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 1 Approved: tcp-ip@sri-nic.arpa but seismo is running 4.3bsd where it is supposedly fixed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607181755.AA18775%40caip.rutgers.edu] <1986071809551500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rbthomas@CAIP.RUTGERS.EDU (Rbthomas) Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP for CDC? Actually TCP/IP for Data-General Message-ID: <8607181755.AA18775@caip.rutgers.edu> Date: Fri, 18-Jul-86 13:55:15 EDT Article-I.D.: caip.8607181755.AA18775 Posted: Fri Jul 18 13:55:15 1986 Date-Received: Sun, 20-Jul-86 03:58:03 EDT References: <8607180413.AA15674@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa I would very much like to hear from any users of Data-General's TCP/IP software that runs under AOS/VS on their MV/ series of computers. We are using it now (I am submitting this using it.) but are having serious stability problems. I would like to hear of any other's experiences. Please reply by mail or voice phone. Thanks in advance! Rick Thomas rbthomas@caip.rutgers.edu ARPAnet princeton!topaz!caip!rbthomas UUCP (210) 932-4301 Voice Phone ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071811514400> Received: from B.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 18 Jul 86 18:52:58-PDT Date: 18 Jul 1986 18:51:44 PDT From: POSTEL@B.ISI.EDU Subject: re: reading list To: tcp-ip@SRI-NIC.ARPA One might start with a paper that appeared in the IEEE Communications Magazine (March 85) and the IEEE INFOCOM '85 Conference. The title is "The DARPA Internet Protocol Suite", the author is B. Leiner. Another paper is "The DoD Internet Architecture Model" by Cerf and Cain in Computer Networks of October 1983. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607182249.AA02374%40ucbvax.Berkeley.EDU] <1986071812132200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dolson@ADA20.ISI.EDU (Douglas M. Olson) Newsgroups: mod.protocols.tcp-ip Subject: VAX IP/TCP Message-ID: <8607182249.AA02374@ucbvax.Berkeley.EDU> Date: Fri, 18-Jul-86 16:13:22 EDT Article-I.D.: ucbvax.8607182249.AA02374 Posted: Fri Jul 18 16:13:22 1986 Date-Received: Sun, 20-Jul-86 04:08:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 131 Approved: tcp-ip@sri-nic.arpa Preface: This one got longer than I had expected. I'd planned a brief query to INFO-VAX for suggestions: but what this missive is REALLY about is a newcomer to the DDN community trying to bring a new installation aboard the net. It is long. I need some help. If this sort of thing isn't your bag, recommend you skip it! --------- From the outside looking in, I'm having a hard time figuring out what I'm supposed to obtain (hardware and software) to make my VAXCluster able to communicate on the DDN using VAX-based instantiations of TELNET, FTP, and (especially important) SMTP. We have just registered our connection requirement through the normal MAJCOM and ASPO channels. They in turn will get our requirement to DCA who will eventually service us with (we are told informally) a 56KB connection. I'm assuming that this connection will be a conditioned circuit from the nearest node, probably over at AFWL on the other side of Kirtland AFB. I'm also aware that the DCA may elect to install a node here in our facility. I'm being quite free with terms that I don't fully understand. For instance, 'node'. I'm assuming this is (with current technology and given the state of the net) the same thing as a C-30. Which runs some node-control software (versions of which I understand are being upgraded to allow older '1822' implementations to communicate with newer 'x.25' { Basic | Standard } implementations...more terms I don't fully understand). I have policy guidance indicating in typical DoD doublespeak that I Shalt Not Plan to use an 1822 interface, as if I could figure out what I wanted. ACC glossies picked up at DEXPO indicate that the IF-11/HDH "operates in HDH (1822-J) Packet Mode" and "the supported link level protocol is HDLC/LAPB"....does that mean its on the verboten list for being 1822 or is it ok for me to buy? As you can see, from what I can tell of the state of the net world, is that things are in flux. What I can't tell is whether the flux affects the decisions I ought to make right now. Due to the fact that we are completely without the flavor of money that lets us make capital expenditures when we need to, we rely TOTALLY on fallout funds to make such purchases. That is, our only budget is Operations and Maintenance; upgrades depend on our being ready to use other peoples unspent money during a very brief window in August and September. If I don't purchase interfaces next month, then DCA may show up with my connection in May next year and we won't be able to buy the interfaces then, and use the connection, until October! I paint that bleak funding picture to explain WHY I need to answer the interfaces question NOW. Hm; actually, what I want is to use some smart box on the same ethernet that services my VAXCluster. This box needs to support up to 100 simultaneous users who have opened connections from TACs around the country. That '100' is usage projected within 3 years; initially, I can probably get by supporting 50-60 simultaneous. Once into the Cluster, on any machine, a user should be able to use FTP and SMTP to exchange with the rest of the internet, presumably transparently using the same connection route...diagrammed here: VAXCluster---(ethernet)----[Smart Box]===(56KB)===C30.... The reasons I want to do it this way is to avoid either 1) buying a separate interface for every single node on the Cluster or 2) buying one interface for one VAX and then burying that VAX serving i/o to the rest of the cluster... is it a ridiculous concept? Are these ridiculous fears? Given that 'what I want' probably doesn't exist; given that I fully expect to have mangled at least one of these concepts and I HOPE you can understand anyway; given that what I'm trying to do is comply with directives to move all long-haul data communication requirements onto the DDN, and my users are scattered from San Diego to West Palm Beach to Boston to Seattle; I have several pleas to make. Simple ones up front: -anybody else already done this? how? are you using x.25 or 1822 interfaces (or is that even a valid question?) -anybody so inclined, straighten out whichever concepts I mangled; -if I belong in another forum, please point; I've been looking for months. More involved issues: Other approaches: We have 3 Ethernet Terminal Servers (each w/32 ports) on the ether now. They support dial-in modems and a few local hardwires. Is there a device which provides a sort of reverse TAC facility? I believe it may be a device I have heard called a PAD (for Packet Assembler/ Disassembler). If I had numerous terminal ports coming in off the C30 via such a device I could connect each port to the Ethernet Terminal Servers over which we have software configuration control. This solves my WORST problem of bringing my remote users in. I could probably then accomodate putting a single interface for FTP and SMTP and outgoing TELNET onto one VAX in the Cluster. Can anyone address whether or not my understanding of a 'PAD' (or whatever its called) is realistic? Is this a reasonable model? Here are three DEC part numbers for "commercial" (vice educational) TCP/IP networking packages; I understand DEC offers these products through a licensing arrangement with The Wollongong Group. QAX74-CM VAX IP/TCP VMS (supports DEUNA and DMR-11 interfaces) QAXA9-CM VAX IP/TCP DDN (supports DEUNA and ACC's IF-11/HDH) QAXX1-C3 IP/TCP MicroVMS (supports DEQNA) (Just to save anyone the hassle of trying to find the "educational" part numbers, here they are: QAX75-CM VAX IP/TCP VMS and QAXX2-C3 IP/TCP MicroVMS...) Are these the best VMS products available? Will any of them support the [Smart Box] prayer I outlined above? Could a MicroVAX II with the QAXX1-C3 possibly be the Smart Box? Could it support 50-100 users, or would I need three (or 'n', tell me your guess at n) of them? If I HAD three of them, how many can be supported by a single C30? If, above, when I asked if my description of a [Smart Box] was a ridiculous concept, you said to yourself, 'yes, ridiculous; he should just use the blotzo' whats your blotzo? I appreciate your patience. I've been digging since February when Bob Tinker from the David Taylor Naval Ship R&D Center asked about ethernet-DDN gateways. As of late April, he privately expressed interest in new technology under development, upon which a product announcement was expected late this year. I don't know if I can wait; I hope you can tell from the tone of this that I have several degrees of uncertainty about our approach. We're ignorant and need help. From the real-(ignorant)-world of real requirements for day-to-day long-haul data-communications, I'm sayin that we're mighty short on solid information. Comments on the above gratefully appreciated. Lt Doug Olson, USAF Air Force Contract Management Division Future Information Systems Program Manager ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607181819.AA27306%40ucbvax.Berkeley.EDU] <1986071816295200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mills@DCN6.ARPA Newsgroups: mod.protocols.tcp-ip Subject: The multi-home problem again Message-ID: <8607181819.AA27306@ucbvax.Berkeley.EDU> Date: Fri, 18-Jul-86 20:29:52 EDT Article-I.D.: ucbvax.8607181819.AA27306 Posted: Fri Jul 18 20:29:52 1986 Date-Received: Sun, 20-Jul-86 03:58:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa Folks, I wondered why it took so long to resolve ISI.EDU names and discovered the following, which I'm sure you will enjoy. A request to resolve A.ISI.EDU sent to [10.0.0.51] (SRI-NIC.ARPA) returns [10.2.0.27], [10.1.33.27], [128.9.0.33], [10.1.0.52] and [128.9.0.32]. The fuzzball namesolver starts cranking on this list and the following nonsense comes back: 16:04:13 Server [10.2.0.27] [responded from address 128.9.0.33] 16:04:18 Server [10.2.0.27] [responded from address 128.9.0.33] 16:04:23 Server [10.2.0.27] [responded from address 128.9.0.33] 16:04:29 Server [10.1.33.27] [no response] 16:04:34 Server [10.1.33.27] [no response] 16:04:39 Server [10.1.33.27] [no response] 16:04:40 Server [128.9.0.33] [responded with requested data [26.3.0.103] Yes, I really mean that the requests to [10.2.0.27] came back, apparently with valid data, but the address in the IP source-address field was [128.9.0.33], which certainly violates the Principle of Least Astonishment. It turns out all three of these addresses belong to VAXA.ISI.EDU, but on different networks, so that host is clearly fuddled. The last buzzard to catch this bug was SRI-NIC.ARPA. Apparently, it bites VAXen too. Hans-Werner Braun reports seeing responses from some servers coming back with [127.0.0.1] in the IP source-address field. That bit of cosmic goofiness would certainly amuse our Martian friends. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986071817341200> Received: from DCN7.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Jul 86 10:37:27-PDT Date: 18-Jul-86 17:34:12-UT From: mills@dcn6.arpa Subject: The multi-home problem again To: tcp-ip@sri-nic.arpa Folks, I wondered why it took so long to resolve ISI.EDU names and discovered the following, which I'm sure you will enjoy. A request to resolve A.ISI.EDU sent to [10.0.0.51] (SRI-NIC.ARPA) returns [10.2.0.27], [10.1.33.27], [128.9.0.33], [10.1.0.52] and [128.9.0.32]. The fuzzball namesolver starts cranking on this list and the following nonsense comes back: 16:04:13 Server [10.2.0.27] [responded from address 128.9.0.33] 16:04:18 Server [10.2.0.27] [responded from address 128.9.0.33] 16:04:23 Server [10.2.0.27] [responded from address 128.9.0.33] 16:04:29 Server [10.1.33.27] [no response] 16:04:34 Server [10.1.33.27] [no response] 16:04:39 Server [10.1.33.27] [no response] 16:04:40 Server [128.9.0.33] [responded with requested data [26.3.0.103] Yes, I really mean that the requests to [10.2.0.27] came back, apparently with valid data, but the address in the IP source-address field was [128.9.0.33], which certainly violates the Principle of Least Astonishment. It turns out all three of these addresses belong to VAXA.ISI.EDU, but on different networks, so that host is clearly fuddled. The last buzzard to catch this bug was SRI-NIC.ARPA. Apparently, it bites VAXen too. Hans-Werner Braun reports seeing responses from some servers coming back with [127.0.0.1] in the IP source-address field. That bit of cosmic goofiness would certainly amuse our Martian friends. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607190220.AA05832%40ucbvax.Berkeley.EDU] <1986071817514400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: POSTEL@B.ISI.EDU Newsgroups: mod.protocols.tcp-ip Subject: re: reading list Message-ID: <8607190220.AA05832@ucbvax.Berkeley.EDU> Date: Fri, 18-Jul-86 21:51:44 EDT Article-I.D.: ucbvax.8607190220.AA05832 Posted: Fri Jul 18 21:51:44 1986 Date-Received: Sun, 20-Jul-86 04:08:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa One might start with a paper that appeared in the IEEE Communications Magazine (March 85) and the IEEE INFOCOM '85 Conference. The title is "The DARPA Internet Protocol Suite", the author is B. Leiner. Another paper is "The DoD Internet Architecture Model" by Cerf and Cain in Computer Networks of October 1983. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12223818492.24.JNC%40XX.LCS.MIT.EDU] <1986071820002700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: Lisp machines don't receive network level broadcasts right, causing net mayhem Message-ID: <12223818492.24.JNC@XX.LCS.MIT.EDU> Date: Sat, 19-Jul-86 00:00:27 EDT Article-I.D.: XX.12223818492.24.JNC Posted: Sat Jul 19 00:00:27 1986 Date-Received: Sun, 20-Jul-86 04:09:53 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa (For those who are lost, this is about the incident I reported where broadcast RIP packets from a subnet gateway were being reforwarded by all of a certain class of machine which didn't recognize them as broadcast, causing a massive jamup on the net.) I sent a message out to TCP-IP a few months (28 April if you want to look it up in the archives) ago in which I discussed a similar topic at length. (The question there was when to send ICMP Error packets). The general philosophy behind the answer here is the same. Had the algorithm about 'hosts not doing anything with wrong packets that were broadcast' been followed by the hosts here, the problem would not have occurred. If a host receives what looks to it like a misdirected packet, it got it either because a gateway was confused or some host was. In the first case, things are really in trouble anyway; reforwarding it could just cause a loop or other serious problems. In the second, I don't think that you should encourage broken behaviour on the part of hosts; if they didn't send the packet to the right place they should be fixed. The real problem is that in practice usually when a host sees a packet it doesn't recognize it's not because the packet was sent to the wrong place, but because there is some strange address in there the host didn't recognize. In this case it was a subnet broadcast address, and a host that didn't recognize that it was on a subnetted net. In the future it might be multicast addresses, or whatever. In either case, doing anything except ignoring it is the wrong thing. Yes, maybe in .001% of the cases, forwarding the packet on is the right thing, but in the rest it's the wrong (and usually disastrous) thing to do. Clearly, the cost/benefit analysis says that forwarding the packet is the wrong thing. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607191215.aa15740%40SEM.BRL.ARPA] <1986071908154500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: RING vs. ETHER - Theory and practice. Message-ID: <8607191215.aa15740@SEM.BRL.ARPA> Date: Sat, 19-Jul-86 12:15:45 EDT Article-I.D.: SEM.8607191215.aa15740 Posted: Sat Jul 19 12:15:45 1986 Date-Received: Sun, 20-Jul-86 07:53:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa Dave Clark once again observes that a token ringnet outperforms an Ethernet in handling back-to-back packets. The ringnet has an automatic retransmission function built into the network interface, and will retransmit rejected packets until they get accepted, while an Ethernet interface loses subsequent packets if they follow the first one too closely. In theory, but let us look at two fielded devices. The INTERLAN N1010A Ethernet interface and the PROTEON 10MB RINGNET. The INTERLAN handles multiple incoming packets by buffering some number of messages comming in from the net in interface memory while waiting for the host to begin the data transfer. The PROTEON can not accept back to back messages because the board does not reset to copying messages from the interface after the end of the first message so it misses the header of the second message. There is no automatic retransmit because the source board drains the ring until it sees its own message come back, which should be at the beginning of the train of messages. It can't leave it in the ring, because it will be eaten by another interface who had transmitted a message. It can't retransmit until the token comes by. I've tried reenabling copy as soon as the DMA has finished, but there is still a delay, and I also feel that something is amis in the interrupt logic when I do this. You are still at a slight win because it is possible for the lower levels to tell when retransmission is needed, however, a lot of retransmission is needed because of the misdesign of the interface, significantly more so than is ever needed on our Ethernets. Not to say that I am down on the Proteons, much of what we are doing at BRL would be difficult or impossible without them. I just wish they could double buffer so that you would not miss the header of successive packets. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607200253.AA02499%40rsch.wisc.edu] <1986071919122600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dave@RSCH.WISC.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: The multi-home problem again Message-ID: <8607200253.AA02499@rsch.wisc.edu> Date: Sat, 19-Jul-86 23:12:26 EDT Article-I.D.: rsch.8607200253.AA02499 Posted: Sat Jul 19 23:12:26 1986 Date-Received: Sun, 20-Jul-86 08:02:49 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa Dave Mills writes: >Yes, I really mean that the requests to [10.2.0.27] came back, apparently with >valid data, but the address in the IP source-address field was [128.9.0.33], This appears to be a bug in the 4.2 and 4.3 UDP implementations. Actually, the way that the network interface between user programs and the kernel is defined, there isn't any way to fix this in all cases. This is because a user program can't specify which of the addresses for a host should be used as the source address. I ran across this bug yesterday while making queries to the UDP time service on one of our hosts. The same sort of thing happened, the source address was not the address to which I had sent the query but the other address for that host. My solution to this problem is to recognize all of the addresses for a host. This seems easier than adding yet another version of the "send" system call to 4.3. I don't think this will help in the case of a name server, though. You can't possibly recognize an address you don't know about! dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607200700.AA24806%40amdahl] <1986071923005700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sjl@amdahl.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ways to input your X.400/MOTIS concerns Message-ID: <8607200700.AA24806@amdahl> Date: Sun, 20-Jul-86 03:00:57 EDT Article-I.D.: amdahl.8607200700.AA24806 Posted: Sun Jul 20 03:00:57 1986 Date-Received: Sun, 20-Jul-86 11:02:08 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa In message <8607150327.AA07564@opus> nbires!atkins@ucbvax (Brian Atkins) states that the Corporation for Open Systems (COS) is a good way to input to the international standards bodies and mentioned the National Bureau of Standards sponsored OSI Implementors Workshop as a less expensive alternative. I appreciate him mentioning the OSI Implementors' Workshops because they have been very important in moving OSI protocols from paper to practice. However, it is important to understand that the main way of affecting standards development is through the national standards committees. The main role of the OSI Implementors' Workshops is to interpret existing standards, although they will sometimes send liaison statements to standards groups. The role of COS is not to represent COS members in standards bodies - members are expected to send their own representatives. COS is intended to accelerate the use and development of OSI and ISDN standards by developing commonly agreed tests and providing a forum in which members are made aware of areas where standards development needs to be accelerated. When discussing COS and the OSI Implementors' Workshops it is useful to know that they have a complementary relationship. COS intends to base the protocol inplementation tests on the agreements reached in the Workshops. COS has also sent the Workshops requests regarding the scheduling and priority of the subjects discussed in the Workshops. A significant number of COS members send representatives to the Workshops. I both attend the OSI Implementors' Workshops and participate in COS activities. As editor of a report produced by the pre-COS group (which led to COS being formed) and as chair of the COS Architecture Committee I have consistently recommended using the agreements reached at the Workshops. However, I do not believe that COS and the OSI Implementors' Workshops currently represent alternatives - they are doing different things. Neither is primarily a method for input to the international standards bodies; this purpose is served by ANSI approved committees or their equivalents in other countries. Stephen J. Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl [ The article above is not an official statement from any organization in the known universe. ] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607201123.aa03545%40SEM.BRL.ARPA] <1986072007234600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: The multi-home problem again Message-ID: <8607201123.aa03545@SEM.BRL.ARPA> Date: Sun, 20-Jul-86 11:23:46 EDT Article-I.D.: SEM.8607201123.aa03545 Posted: Sun Jul 20 11:23:46 1986 Date-Received: Mon, 21-Jul-86 00:34:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa It is not necessary to add a new version of the send call, I believe sendmsg allows you to specify an arbitrary source address, but it is a little harder to deal with. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12224206784.24.JNC%40XX.LCS.MIT.EDU] <1986072007332400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: RING vs. ETHER - Theory and practice. Message-ID: <12224206784.24.JNC@XX.LCS.MIT.EDU> Date: Sun, 20-Jul-86 11:33:24 EDT Article-I.D.: XX.12224206784.24.JNC Posted: Sun Jul 20 11:33:24 1986 Date-Received: Mon, 21-Jul-86 00:41:37 EDT References: <8607191215.aa15740@SEM.BRL.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 45 Approved: tcp-ip@sri-nic.arpa First, let me correct some misstatements in both your characterization of the ring systems (one of which I had a hand in designing at MIT). It does not automatically retransmit packets; perhaps the person was confusing it with Ethernet interfaces which do retransmit packets automatically in case of a collision. Also, the 80MB ring interface does have on board packet buffer and it will receive back to back packets without host intervention, although the 10MB ring interface does not. What both 10M and 80M *do* have (as you alluded to) is a low level *acknowledgment*. I.e., you know (with some reasonable degree of probability) whether or not the intended recipient got the packet. The reason I think that this is important is because it is starting to become clear that dropping packets is a Bad Thing in terms of the effect on performance. Any losses and retransmissions have serious effects on the performance of 'single-ACK' protocols like TCP, especially when you are running at high data rates. The single ACK is such a weak mechanism that it should only be used as a backstop for rare failures; if you have to use it a lot, you lose a lot of performance. Since we are stuck with TCP -> you should not drop packets. The point of all this is that nets ought to have a reasonable hardware acknowledgement feature that would let you know when a host could not accept a packet destined to it. I don't know why the didn't put one in Ethernet; it would have been really trivial. The CHAOS hardware built at the MIT AI Lab (which was a 4MB/sec Ether like system) had such a feature; the recipient jammed the cable (causing a collision) if a packet for that destination could not be handled. What amazes me is that although the IEEE Ethernet spec did make all sorts of changes to the spec, of little or no pactical utility as far as I can see (e.g. Ethernet demonstrably works fine without a length field), they didn't fix this glaring defect! A typical standards committee: they make all sorts of gratuitous changes to an existing widespread spec, resulting in a massive incompatability problem, without fixing any real problems. I guess it is true that with a multi-buffered interface you are less likely to drop packets, but it still does help. Also, low level acks can help gateways a lot. If the next hop gateway on a route dies, you can detect it, and reroute around it. You can also give more informative error messages. (How I hate 'connection timed out' - I want to know why! The annoying thing is that even when gateways go to great lengths to send back ICMP error messages, most hosts do not reflect them to users. When I put ICMP error support into a gateway, I could not find a host at MIT that would take the messages and use them to make an intelligent error message for the user!) Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12224258785.54.LIXIA%40XX.LCS.MIT.EDU] <1986072012190300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Lixia@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: RING vs. ETHER - Theory and practice. Message-ID: <12224258785.54.LIXIA@XX.LCS.MIT.EDU> Date: Sun, 20-Jul-86 16:19:03 EDT Article-I.D.: XX.12224258785.54.LIXIA Posted: Sun Jul 20 16:19:03 1986 Date-Received: Mon, 21-Jul-86 02:42:36 EDT References: <12224206784.24.JNC@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa I wrote the original paragraph of Dave Clark once again observes that a token ringnet outperforms an Ethernet in handling back-to-back packets. The ringnet has an automatic retransmission function built into the network interface, and will retransmit rejected packets until they get accepted, while an Ethernet interface loses subsequent packets if they follow the first one too closely. So I'd better clean up my own mistake. As Noel has pointed out, the ringnet interface returns an acknowledgment; therefore when the receiving interface cannot catch up with incoming packets, the source host network driver quickly retransmits any negatively acknowledged packet till the interface returns an positive-ACK (or till hits some max retrans number). For Ethernet, if the receiving interface doesn't get a packet right, the packet is lost. Having buffers at the interface is helpful, for both ethernet and ring. Ethernet is a loser in that, using Noel's word, it lacks a low-level ACK. Lixia ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D20-Jul-86.23:30:12.CERF] <1986072019300000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: RING vs. ETHER - Theory and practice. Message-ID: <[A.ISI.EDU]20-Jul-86.23:30:12.CERF> Date: Sun, 20-Jul-86 23:30:00 EDT Article-I.D.: <[A.ISI.EDU]20-Jul-86.23:30:12.CERF> Posted: Sun Jul 20 23:30:00 1986 Date-Received: Mon, 21-Jul-86 07:42:19 EDT References: <12224206784.24.JNC@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Noel, Please elaborate on "single ACK" problem. As you know, TCP ACKS are at least "inclusive" so that subsequent ACK can make up for one lost, if more data is sent and received. This isn't perfect, of course, since "inclusive" ACK doesn't help if data was lost at the receiver. Perhaps you are thinking about ACKs which cover data received past data lost (selective ACKS)? We looked at this several times but the complexity of the mechanism did not seem to buy enough to justify it. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986072019300001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 20 Jul 86 20:32:28-PDT Date: 20 Jul 1986 23:30-EDT Sender: CERF@A.ISI.EDU Subject: Re: RING vs. ETHER - Theory and practice. From: CERF@A.ISI.EDU To: JNC@XX.LCS.MIT.EDU Cc: ron@BRL.ARPA, TCP-IP@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]20-Jul-86 23:30:12.CERF> In-Reply-To: <12224206784.24.JNC@XX.LCS.MIT.EDU> Noel, Please elaborate on "single ACK" problem. As you know, TCP ACKS are at least "inclusive" so that subsequent ACK can make up for one lost, if more data is sent and received. This isn't perfect, of course, since "inclusive" ACK doesn't help if data was lost at the receiver. Perhaps you are thinking about ACKs which cover data received past data lost (selective ACKS)? We looked at this several times but the complexity of the mechanism did not seem to buy enough to justify it. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607210511.AA02538%40cbosgd.ATT.COM] <1986072021114400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mark@cbosgd.ATT.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: RING vs. ETHER - Theory and practice. Message-ID: <8607210511.AA02538@cbosgd.ATT.COM> Date: Mon, 21-Jul-86 01:11:44 EDT Article-I.D.: cbosgd.8607210511.AA02538 Posted: Mon Jul 21 01:11:44 1986 Date-Received: Mon, 21-Jul-86 20:28:07 EDT References: <12224206784.24.JNC@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa In article <12224206784.24.JNC@XX.LCS.MIT.EDU> you write: > The point of all this is that nets ought to have a reasonable >hardware acknowledgement feature that would let you know when a host could >not accept a packet destined to it. I don't know why the didn't put one in >Ethernet; it would have been really trivial. The CHAOS hardware built at >the MIT AI Lab (which was a 4MB/sec Ether like system) had such a feature; >the recipient jammed the cable (causing a collision) if a packet for that >destination could not be handled. I note that 802.2 has a whole bunch of "connection oriented" features added onto the side of Ethernet. While I assume most of us are ignoring them (I gather they were put there by X.25 types) I wonder if there would be a clean way to use these facilities to get an ack or nak back for normal IP type datagrams? Since I gather we have some standards to work out regarding ARP on 802.2 anyway, maybe this would be a good time to adopt some other conventions too? Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607210614.AA07696%40monet.Berkeley.EDU] <1986072022142800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels@MONET.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: The multi-home problem again Message-ID: <8607210614.AA07696@monet.Berkeley.EDU> Date: Mon, 21-Jul-86 02:14:28 EDT Article-I.D.: monet.8607210614.AA07696 Posted: Mon Jul 21 02:14:28 1986 Date-Received: Mon, 21-Jul-86 20:12:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 58 Approved: tcp-ip@sri-nic.arpa The previous answer to Dave Mills' observation on the nameserver for A.ISI.EDU requires considerable clarification and correction. Actually, I was going to deny any responsibility on behalf of 4.2 and 4.3BSD UNIX for dealings between a fuzzball and TOPS-20, but a quick check shows that the server for ISI now runs on a 4.2BSD VAX. I guess I'm not off the hook so easily. The previous reply was totally incorrect in its claims about 4.3. However, 4.2 has a serious problem when it comes to the Principle of Least Astonishment when it comes to UDP return addresses. First, a process receiving UDP datagrams (including a server) receives the datagram "from" address, but not the "to" address. Thus, a server can take no action to ensure that the source address of its reply is the same as the destination address of the request on a multihomed host. (The preceeding is still true in 4.3.) Both 4.2 and 4.3 attempt to choose UDP source addresses according to the destination address, but 4.2 makes a somewhat feeble attempt. It uses its address on a network shared with the destination, if any (which is generally correct), but uses its "primary" address for all other destinations. The "primary" address is the address for the first network interface in the system configuration file. VAXA.ISI.EDU could apparently be helped considerably by placing its imp interface first in its kernel configuration table. 4.3 makes a better attempt at choosing source addresses for datagrams (and client-initiated TCP connections). It uses its address on the network through which it routes the packet. However, for the name-domain system, this is not sufficient that name solvers may depend on the server's choice of source address. In particular, if the server is known by multiple addresses, the name solver may or may not use the "closest" address for the server (the address on the network by which the request will arrive). It seems to be reasonably simple to recognize a reply to one's query, however, without depending on the source address of the reply. That is fortunate, as the predominant servers run on hosts that may not use the expected source address for all replies. The comments made by Dave Cohrs about the "UDP bug" concerning inability to specify the source address of a datagram were incorrect. It is possible for the source address to be bound (using the bind system call) before sending the datagram. It would be reasonable for a knowledgeable server to set up one descriptor for each source address in this way. It is actually the system interface for reception of datagrams that is limiting. By the way, the Martian-grams which Dave Mills mentioned (replies from 127.0.0.1) are more difficult to explain. The last wave of attacks were ICMP error messages with that source address that came from a beta 4.3 host. The code to select the ICMP source address was unfinished at the time of the beta release, although I had forgotten that by the time of the attack. The test release thus used the "primary" address, which in 4.3 is the first address set. At one site, the primary address was thus the one used for the loopback, a configuration error that I had not imagined. The error would be much less serious with the released version of 4.3. Seismo appears to still be running the beta test version or a mixture of the two. With either version, the loopback address can be set to any value. To encourage use of officially-assigned addresses, the release contains an unusable definition of the loopback address that must be changed. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986072102515500> Received: from NRL-LCP.ARPA by SRI-NIC.ARPA with TCP; Mon 21 Jul 86 09:51:55-PDT Date: Mon 21 Jul 86 09:51:55-PDT From: "Robert J. Scott" Subject: please remove To: "tcp-ip" Reply-To: "Robert J. Scott" Dear List Maintaniner. We would like to be removed from the tcp-ip distribution list as we are being overwhelmed with messages that we can't give sufficient time. thank you, NRL-LCP ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607211509.AA12215%40ucbvax.Berkeley.EDU] <1986072105131600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@BRUBECK.PROTEON.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: RING vs. ETHER - Theory and practice. Message-ID: <8607211509.AA12215@ucbvax.Berkeley.EDU> Date: Mon, 21-Jul-86 09:13:16 EDT Article-I.D.: ucbvax.8607211509.AA12215 Posted: Mon Jul 21 09:13:16 1986 Date-Received: Mon, 21-Jul-86 21:34:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jas@proteon.com Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa I'll answer two open questions at once here. The 802.2 connection oriented features probably really exist so that IBM could run SNA on "their" 802.5 Token-Ring Network. SNA absolutely requires a reliable data-link layer, this is essentially the only level where there are any data integrity features in the SNA architecture. That's why IBM's Token-Ring board has a complete 802.2 connection oriented (VC) in the firmware of their PC board, along with an extended XID frame for SNA. I don't think that using a VC data link for IP is going to help you on a LAN. First of all, nobody's going to manage to write a 6-10 megabit/sec 802.2 VC layer. Secondly, stacking VC layers does not always work well. Third, this is not really the way TCP/IP was intended to be used. (Of course, on slow nets like the ARPANET, the VC code does not get in the way.) Fourth, the sequence numbering is only modulo-128. This can get consumed rapidly by tinygrams, and you will go into senquence number wait. On the issues of single ACK in TCP, this has to do with degenerative congestion when packets are being dropped. The sender sends 5120 bytes in ten TCP packets. The second one gets dropped due to congestion. The ACK of the first comes back. The last 8 packets get retransmitted. The second one (orignal fourth) gets dropped due to congestion. Repeat. What we have is a tendency towards instability when packets start getting lost. Note that the congestion is getting worse for eveyone due to this, since packets are being sent many extra times. This sort of problem is why people are developing protocols with what I call "ACK vectors", such as NETBLT at MIT, and NETEX from Network Systems. These provide the fate of the last 'n' packets in ACKs, rather than a ACK-point. Only the dropped packet gets retransmitted in these protocols. john shriver proteon ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SST.D-BIGELOW.12224443966.BABYL%40KLA.WESLYN] <1986072105160000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SST.D-BIGELOW%KLA.WESLYN%Wesleyan.BITNET@WISCVM.WISC.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Tektronix TCP/IP news? Message-ID: Date: Mon, 21-Jul-86 09:16:00 EDT Article-I.D.: KLA.SST.D-BIGELOW.12224443966.BABYL Posted: Mon Jul 21 09:16:00 1986 Date-Received: Mon, 21-Jul-86 20:48:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa Bob, a TEKTCP mailing list has indeed been created. The address is TEKTCP%KLA.Weslyn@Wesleyan.Bitnet, and requests go to TEKTCP-Request%KLA.Weslyn@Wesleyan.Bitnet. I'll go ahead and add you to the list. It just started a week or so ago, with less than two dozen people. If it grows much I'll ask for redistribution points for nets other than Bitnet, but for now it's a low-volume, non-moderated rebroadcast list. Topics are anything having to do with using the Tektronix TCP/IP package on VAX/VMS. Regarding your specific questions about Tek TCP, I'll send you more information in a separate message without CCs. -- Doug ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.leong.139.3%40andrew.cmu.edu] <1986072109125400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leong@ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: Re: RING vs. ETHER - Theory and practice. Message-ID: Date: Mon, 21-Jul-86 13:12:54 EDT Article-I.D.: andrew.MS.leong.0.leong.139.3 Posted: Mon Jul 21 13:12:54 1986 Date-Received: Tue, 22-Jul-86 03:39:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa In IEEE802.5 (a.k. IBM token ring), there is two low level acknowlegemnt of sort in the MAC layer encapsulation - at the end of the frame. When a station grap a token for transmission, it will set the A and C bits (Address Recognised and Frame Copied) to 0. As the frame zap round the ring, if all goes well, the detsination station will receive the frame and set both the A and C bits to 1. When the frame continues its merry way back to the sender for purging, the sender can deduce from the status of the A and C bit what has happened. If A and C are both set to 1, all's well. If A and C are 0, there is a good probability that the destination is not up or on the net. If A is 1 and C is 0 then the receiving station has a congestion problem. If A is 0 and C is 1, we have something really strange going on. Note that the acknowlegement is all done within one ring rotation as the A and C bit is flipped on the fly by the receiver and is very efficient. There is no explicit ACK frame involved. Furthermore, the IBM token ring has a nifty feature built into the chip set. If an interface detects a congestion situation, it will send out a special frame (MAC frame) to tell whoever wants to know (network monitoring station) that a soft error situation has been detected. It is really useful for network management and planning. Leong ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.leong.139.5%40andrew.cmu.edu] <1986072110445600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leong@ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: Re: RING vs. ETHER - Theory and practice Message-ID: Date: Mon, 21-Jul-86 14:44:56 EDT Article-I.D.: andrew.MS.leong.0.leong.139.5 Posted: Mon Jul 21 14:44:56 1986 Date-Received: Tue, 22-Jul-86 03:44:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Mark, Re : 802.2 Type 2 operation 802.2 offers you Type 1 or Type 2 operation. Type 1 is pure datagram stuff with the ARPANET's "take your chance" approach while Type 2 goes the other extreme and do both flow control and error recovery. The general idea is that if you are going for a heavy weight Tranpsort Layer already such as TCP or TP-4, you should leave every thing to that layer and chose Type 1. If you are going to use light weight Tranpsort layer such as TP-0, then Type 2 is for you. (Interestingly, IBM is using Type 2 since under SNA, the link layer is the only level that will do error recovery). Hence unless we can get IEEE802.2 to create a Type 1.5, we don't think it is worth our while to spend the cycles required for Type 2. (Actually, having a Type 1.5 that will do low level acknowlegement but without flow control and error recovery procedure may be quite useful - particularly for network level gateway machines). Leong ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607211927.AA05073%40mouton.bellcore.com] <1986072111275300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@MOUTON.BELLCORE.COM (Phil R. Karn) Newsgroups: mod.protocols.tcp-ip Subject: TCP retransmission efficiency Message-ID: <8607211927.AA05073@mouton.bellcore.com> Date: Mon, 21-Jul-86 15:27:53 EDT Article-I.D.: mouton.8607211927.AA05073 Posted: Mon Jul 21 15:27:53 1986 Date-Received: Tue, 22-Jul-86 07:23:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa A virtual circuit link layer on Ethernet? Surely you jest! I guess Ethernet was too simple, cheap, fast and reliable to be left alone by IBM. Must be the second law of thermodynamics in action... I'm not sure John Shriver's scenario with TCP is up to date. More modern implementations ("modern" defined as "implementing John Nagle's recommendations in RFC 896") seldom suffer from this problem. First of all, in the majority of situations the Nagle Rule allows only one segment to be in flight at a time. Obviously a lot of problems go away if you can operate in "stop and wait" mode. Only when the bandwidth requirement on the connection exceeds one Maximum Segment Size per round trip interval will there be more than one segment in flight at one time. (This assumes that the receive window is greater than the MSS, of course.) Even so, if an early segment gets lost, the receiving TCP is supposed to place the later segments on its resequencing queue and quietly await retransmission of the missing segment. When the sender times out, it is supposed to resend ONLY the oldest unacknowledged segment. This fills in the hole, and the receiver will now acknowledge all the segments that it has received. The transfer now continues without any unnecessary retransmissions. So as long as the receiver uses "in-window" acceptance (i.e., implements resequencing) and the sender uses "first-only" retransmission, it's pretty easy to see that only those segments actually lost are retransmitted. And this is done without any incompatible changes to the protocol. Of course, this assumes that ACKs aren't lost very frequently. If they are, then it makes sense to consider ACKing ACKs. I.e., ACKs are retransmitted by the receiver until it gets either a new data packet from the transmitter or an indication that there is no more data to send. This looks like a good idea on very lossy networks (e.g., packet radio -- this idea was first proposed by the Alohanet folks) and I've proposed it for use as an experimental amateur packet radio link level protocol. At the transport layer, however, you had better have reasonably low loss rates or the more costly end-to-end retransmissions (even ACK retransmissions) would eat you alive. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607211944.AA17018%40ucbvax.Berkeley.EDU] <1986072111462100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: scott@nrl-lcp ("Robert J. Scott") Newsgroups: mod.protocols.tcp-ip Subject: please remove Message-ID: <8607211944.AA17018@ucbvax.Berkeley.EDU> Date: Mon, 21-Jul-86 15:46:21 EDT Article-I.D.: ucbvax.8607211944.AA17018 Posted: Mon Jul 21 15:46:21 1986 Date-Received: Tue, 22-Jul-86 03:35:18 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Robert J. Scott" Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Dear List Maintaniner. We would like to be removed from the tcp-ip distribution list as we are being overwhelmed with messages that we can't give sufficient time. thank you, NRL-LCP ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607211414.AA11827%40puff.wisc.edu] <1986072113582000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dave@RSCH.WISC.EDU (Dave Cohrs) Newsgroups: mod.protocols.tcp-ip Subject: Re: The multi-home problem again Message-ID: <8607211414.AA11827@puff.wisc.edu> Date: Mon, 21-Jul-86 17:58:20 EDT Article-I.D.: puff.8607211414.AA11827 Posted: Mon Jul 21 17:58:20 1986 Date-Received: Tue, 22-Jul-86 03:41:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Sorry about the mis-info. I didn't realize that 4.3 was that different from 4.3alpha and 4.3beta. Thanks for the clarification. dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986072116140000> Received: from WISCVM.ARPA by SRI-NIC.ARPA with TCP; Mon 21 Jul 86 18:16:20-PDT Received: from (GNAGARAJ)SUNRISE.BITNET by WISCVM.ARPA on 07/21/86 at 20:16:02 CDT Date: Mon, 21 Jul 86 21:14 EST From: (Gopal Nagarajan | 423-3003 |) Subject: To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa Please delete me from your mailing list. Thank you. G Nagarajan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607220256.AA24208%40ucbvax.Berkeley.EDU] <1986072118140000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GNAGARAJ@SUNRISE.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8607220256.AA24208@ucbvax.Berkeley.EDU> Date: Mon, 21-Jul-86 22:14:00 EDT Article-I.D.: ucbvax.8607220256.AA24208 Posted: Mon Jul 21 22:14:00 1986 Date-Received: Wed, 23-Jul-86 00:32:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa Please delete me from your mailing list. Thank you. G Nagarajan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986072200590000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Tue 22 Jul 86 09:09:13-PDT Date: 22 Jul 86 08:59:00 PST From: Subject: Confused in VAX/DDN Land To: "tcp-ip" Reply-To: Doug, Please give me a call here at ACC. I will attempt to set the record straight on our products as well as give you some guidance as to how you may want to approach your application...don't feel like the Lone Ranger...many others such as yourself are asking the same questions.. Tonto is not far behind... Gary ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607221703.AA04017%40ucbvax.Berkeley.EDU] <1986072208590000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gary@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Confused in VAX/DDN Land Message-ID: <8607221703.AA04017@ucbvax.Berkeley.EDU> Date: Tue, 22-Jul-86 12:59:00 EDT Article-I.D.: ucbvax.8607221703.AA04017 Posted: Tue Jul 22 12:59:00 1986 Date-Received: Wed, 23-Jul-86 03:29:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Doug, Please give me a call here at ACC. I will attempt to set the record straight on our products as well as give you some guidance as to how you may want to approach your application...don't feel like the Lone Ranger...many others such as yourself are asking the same questions.. Tonto is not far behind... Gary ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607222305.AA11853%40ucbvax.Berkeley.EDU] <1986072216475300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mills@DCN6.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Undocumented service ports Message-ID: <8607222305.AA11853@ucbvax.Berkeley.EDU> Date: Tue, 22-Jul-86 20:47:53 EDT Article-I.D.: ucbvax.8607222305.AA11853 Posted: Tue Jul 22 20:47:53 1986 Date-Received: Wed, 23-Jul-86 19:22:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Folks, Our spacewatch network reports sighting TCP connections to port 104, which is not an assigned number according to RFC-960. This number, however, is in the range usually associated with a standard network service and is assigned only after public disclosure and documentation. I suspect from context this number has been assigned our X.400 crew, which leads me to politely inquire if encapsulation information is available so we can all claim our First-Crash Awards. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986072222270900> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Tue 22 Jul 86 15:34:38-PDT Date: 22-Jul-86 22:27:09-UT From: mills@dcn6.arpa Subject: Undocumented service ports To: tcp-ip@sri-nic.arpa Folks, Our spacewatch network reports sighting TCP connections to port 104, which is not an assigned number according to RFC-960. This number, however, is in the range usually associated with a standard network service and is assigned only after public disclosure and documentation. I suspect from context this number has been assigned our X.400 crew, which leads me to politely inquire if encapsulation information is available so we can all claim our First-Crash Awards. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607231417.AA24287%40ucbvax.Berkeley.EDU] <1986072305341400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@BRUBECK.PROTEON.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: RING vs. ETHER - Theory and practice Message-ID: <8607231417.AA24287@ucbvax.Berkeley.EDU> Date: Wed, 23-Jul-86 09:34:14 EDT Article-I.D.: ucbvax.8607231417.AA24287 Posted: Wed Jul 23 09:34:14 1986 Date-Received: Thu, 24-Jul-86 02:58:35 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jas@proteon.com Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa There is a proposed type 3 802.2 under consideration, which is reliable datagram. Still, the A and C bits help so much that I'm not so sure this will be valuable for TCP/IP. john shriver proteon ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860723115811.6.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986072307580000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: Computer Implementations Sociologists Message-ID: <860723115811.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Wed, 23-Jul-86 11:58:00 EDT Article-I.D.: FIREBIRD.860723115811.6.DCP Posted: Wed Jul 23 11:58:00 1986 Date-Received: Thu, 24-Jul-86 03:27:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa I'm wondering if there are any social scientists that study why various aspects of computers exist the way they do. My current questions relate to languages and network protocols. Other topics include computer architectures, operating systems and I'm sure several others. Languages is an older field. I'm not really interested in a simple history of FORTRAN or BASIC or COBOL or ADA or CommonLisp. I'm more interested in the overall motivations, goals and constraints placed upon the designers, how well the result met the goals, what problems the language didn't solve, how the goals were found to be faulty, how the goals change over time (e.g., as memory and disk gets cheaper), etc. This goes all the way from conception, implementation, revision, widespread usage, evolution, etc. Networks are a newer field, but certainly has had its share of good and bad ideas. Again, I'm not interested in a simply history of the ARPAnet, LANs, etc. I'm interested in such things as the constraints under which designers use numeric encoding instead of symbolic values. Is it host language support? Is it to reduce byte count for 1970 packet charges that haven't evaporated in this the information age? Is it just historical inertia? Has anybody studied the "Not made here" syndrome? What is the cause of it? Is it simple arrogance, or do original designers plan things too specifically that can be generalized? If so, do they realize what they are doing, or does one learn to be more general as one gets older and wiser? How do protocols become imposed on people? What is the effect of the imposition? Has anybody studied possible hypocrisy among designers? For example, if a standard is to be imposed, what if it is known to be unsuitable for some organization? How many things are done because of underying, and possibly not realized, job security desires? Those are the types of questions/debates I'm interested in seeing outsider study results. I'm sure we all have opinions on some of the above. I do. Doing some soul searching to learn why one has opinions can sometimes be very enlightening. Any leads on professionals or publications that address these? Replies to me only, please. I'll redistribute replies to interested individuals. I'd be interested in actively discussing this, but I don't have time in the short term. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607231809.AA11574%40ucbopal.Berkeley.Edu] <1986072310090700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: minshall%ucbopal@UCBVAX.BERKELEY.EDU (Greg Minshall) Newsgroups: mod.protocols.tcp-ip Subject: tn3270 fixes (thanks!) Message-ID: <8607231809.AA11574@ucbopal.Berkeley.Edu> Date: Wed, 23-Jul-86 14:09:07 EDT Article-I.D.: ucbopal.8607231809.AA11574 Posted: Wed Jul 23 14:09:07 1986 Date-Received: Thu, 24-Jul-86 03:31:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Bob and Alan, I would like to thank you all a lot. Your collectively inspired mods to tn3270 will save me a fair amount of work. I will incorporate these changes as soon as I am back on campus regularly - so it may be another month or so. Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607280259.AA21383%40monet.Berkeley.EDU] <1986072718591700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels@MONET.BERKELEY.EDU (Mike Karels) Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP retransmission efficiency Message-ID: <8607280259.AA21383@monet.Berkeley.EDU> Date: Sun, 27-Jul-86 22:59:17 EDT Article-I.D.: monet.8607280259.AA21383 Posted: Sun Jul 27 22:59:17 1986 Date-Received: Mon, 28-Jul-86 04:34:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa Phil: I'm not sure you're up to date on TCP either. The Nagle algorithm allows only one *small* packet in flight (one of less than the maximum segment size). Essentially all applications other than telnet/remote terminal use more than one segment per round-trip interval. Very few applications are satisfied with "stop and wait" mode, nor do they refrain from sending additional data once a maximum segment sized packet has been sent. I don't want to think about ACKing ACKs; new data segments are sufficient acknowledgement, and retransmitted data segments are good enough NAKs. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607280403.AA00258%40ka9q.bellcore.com] <1986072720033900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@KA9Q.BELLCORE.COM (Phil Karn) Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP retransmission efficiency Message-ID: <8607280403.AA00258@ka9q.bellcore.com> Date: Mon, 28-Jul-86 00:03:39 EDT Article-I.D.: ka9q.8607280403.AA00258 Posted: Mon Jul 28 00:03:39 1986 Date-Received: Mon, 28-Jul-86 04:41:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Forget the Nagle algorithm for the moment; I confused the issue by bringing it up. Assuming ACKs aren't lost, unnecessary retransmissions are avoided as long as you have "first only" retransmission at the sender plus "in window" acceptance at the receiver. As I said, "ack retransmission" (i.e., acking acks) is a last-ditch approach for use over very unreliable links. I'm not sure it'd be at all appropriate at the transport (host-host) layer. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607281639.AA00205%40apolling.imagen.uucp] <1986072808391100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@imagen.UUCP (Geof Cooper) Newsgroups: mod.protocols.tcp-ip Subject: Throughput to IMAGEN TCP-IP Printers running V2.1 & V2.2 Message-ID: <8607281639.AA00205@apolling.imagen.uucp> Date: Mon, 28-Jul-86 12:39:11 EDT Article-I.D.: apolling.8607281639.AA00205 Posted: Mon Jul 28 12:39:11 1986 Date-Received: Wed, 30-Jul-86 00:40:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.dec.com Organization: The ARPA Internet Lines: 70 Approved: tcp-ip@sri-nic.arpa There is a bug that affects throughput in IMAGEN's V2.1 and V2.2 TCP software. For people who are familiar with TCP-IP, the bug is explained below. The bug limits throughput to 32 Kbits/s when the sending TCP's buffer space is less than 6144 bytes. This is the case, by default, for BSD 4.2 UNIX systems (including SUN's). The bug is fixed in IMAGEN's release V3.3 software, which is now in beta test. 32 Kbits/s is sufficient throughput for most documents, since the printer processes most data no faster than this. Bitmap data is the exception (especially when using language bitarray but also when using IMPRESS), since the image processor would process this data faster if it were received faster. TCP sites may improve throughput for bitmap data by increasing the amount of "send" buffer space to be >= 6144 bytes. UNIX sites can accomplish this without resort to sources, by patching the UNIX kernel to set the variable "tcp_sendspace" to be 6144: # adb -w /vmunix /dev/kmem tcp_sendspace/W 0x1800 tcp_sendspace: 0x800 = 0x1800 $q # This patches the in-memory copy of UNIX (the one that is running now). The same patch, with a question mark instead of a slash (tcp_sendspace?W) will alter the bootable binary, causing the patch to be automatically installed every time the system is rebooted. The effect of the patch is to increase the buffer space reserved for outgoing data for every TCP connection to be 6144 bytes. It is not possible to change this parameter for specific connections, so the global limit must be changed. The impact on the system is to reserve 4KB more memory per connection, so the memory requirements of the UNIX kernel will rise slightly. [Somewhat improved throughput between UNIX systems can be achieved by also setting the kernel variable tcp_recvspace to be 6144 for both cooperating systems. I have not measured the speed improvement in this case]. Explanation of bug: ================== The IMAGEN TCP software is an "upcall" implementation, such that there are no per-connection packet queues. Each packet is individually and fully processed as it is received. When a packet containing data is received, the software sets a flag to generate an ACK. If the packet consumes more than a particular percentage of the offered window, the ACK is sent immediately. Otherwise, there might be another packet waiting to be processed at the network interface, so the ACK is withheld to allow additional packets to share the same ACK. A timer is set for a short delay (1/2 a second), after which the ACK is sent anyway. The bug occurs when the amount of buffer space for that the sending TCP has reserved for outgoing data, say N bytes, is much less than the offered window, say M bytes. In this case the "short delay" lasts its full duration after each burst of N bytes. The throughput of the connection is thus very close to N/.5 or 2N bytes per second, since the time to actually transmit the data is dominated by the "pregnant pause" waiting for the printer's timer to expire. In the case of a BSD4.2 system, the default for tcp_sendspace is N=2048, so the throughput is close to 4 Kbytes or 32 Kbits/second. The fix is to increase the sender's buffer space such that the send buffer space is as great as the offered window (N >= M). This ensures that the printer will send an ACK when it receives all the data the host is able to send. As mentioned above, the bug is fixed in IMAGEN's V3.3 software. - Geof Cooper IMAGEN ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986073008252400> Received: from glacier.stanford.edu by SRI-NIC.ARPA with TCP; Wed 30 Jul 86 15:24:44-PDT Received: by glacier.stanford.edu with Sendmail; Wed, 30 Jul 86 15:25:24 pdt Date: Wed, 30 Jul 86 15:25:24 pdt From: John B. Nagle Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: RING vs. ETHER - Theory and practice. Summary: Expires: References: <8607211628.AA13382@ucbvax.Berkeley.EDU> Sender: Reply-To: jbn@glacier.UUCP (John B. Nagle) Followup-To: Distribution: Organization: Stanford University, IC Laboratory Keywords: Apparently-To: tcp-ip@sri-nic.arpa 1. If you are losing packets due to having too few receiving buffers in your Ethernet controller, get a modern Ethernet controller. The worst known offender is the old 3COM Multibus Ethernet controller used in early SUN systems; not only does it have only two receiving buffers, it has no overrun detection, and thus the software never tallies the many packets it tends to lose. 2. If you are losing packets due to congestion problems in a TCP-based system, this can be fixed; see my various RFCs on the subject. "Improving" the protocol by adding extra acknowledgements or fancier retransmission schemes is NOT the answer. I've developed some workable solutions that are documented in RFCs and implemented in 4.3BSD. 3. The real need for link-level acknowledges, or at least some indication of non-delivery that works most of the time, is for routing around faults. Ethernets transmit happily into black holes; when the destination dies, the source never knows. When the destination Ethernet node is a gateway, and said gateway goes down, there is no low-level way for the sending Ethernet node to notice this and divert to an alternate gateway. This is a serious problem in hi-rel systems, because we have no standard way for a host on a multi-gateway Ethernet to behave which will cause it to divert from one gateway to another when one gateway fails. There are a number of approaches to this problem, all of them lousy: - Ignore it and put up with at least minutes and perhaps indefinite downtime when a supposedly redundant gateway fails. (Considered unacceptable in military systems) - Shorten the ARP timeout to 10 seconds or so and spend excessive resources sending ARPs. (Tends to cause one retransmit every 10 seconds due to non-clever ARP implementations). - Let the hosts participate in some kind of nonstandard routing protocol so they can tell when a gateway dies. (No good for off-the-shelf hosts). - Let the transport layer inform the datagram layer when a retransmit occurs, so that the datagram layer can trigger the selection of a different gateway; if this causes selection of an up but ill-chosen gateway, a redirect from that gateway corrects the situation. (Some code to do this is in 4.2BSD, but it wasn't fully implemented.) It's all so much easier if you have link-level failure-to deliver indications. John Nagle ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607301948.AA29153%40ACC-SB-UNIX.ARPA] <1986073011482400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cam@ACC-SB-UNIX.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Directory manipulation support in server FTP's Message-ID: <8607301948.AA29153@ACC-SB-UNIX.ARPA> Date: Wed, 30-Jul-86 15:48:24 EDT Article-I.D.: ACC-SB-U.8607301948.AA29153 Posted: Wed Jul 30 15:48:24 1986 Date-Received: Thu, 31-Jul-86 17:39:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa User FTP on our BSD 4.2 system supports some "experimental" commands: pwd, mkdir, and rmdir. Use of these commands results in XPWD, XMKD, or XRMD being sent to the FTP server. The BSD 4.2 server recognizes and handles these commands appropriately. As far as I know, this is vanilla 4.2 operation; we have not modified User or Server FTP in our system. Appendix II in the latest FTP RFC (RFC959) specifies that PWD, MKD, and RMD should be sent to an Server FTP to request the appropriate directory operation. Does BSD 4.3 support the commands in Appendix II of RFC959? Does it also remain compatible with 4.2 by supporting the X... versions of the commands? Where do other FTP servers stand in respect to support for the directory commands (MKD, PWD, RMD, CDUP) specified in Appendix II of RFC959? Do any other servers support the X... "experimental" commands? If anybody is familiar with 4.3 FTP operation or the FTP operation of other FTP Servers and could comment on these questions, I would certainly appreciate it. Thanx. Chris Markle (cam@acc-sb-unix.arpa 301-997-9373) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607302323.AA13783%40ucbvax.Berkeley.EDU] <1986073014252400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jbn@GLACIER.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: RING vs. ETHER - Theory and practice. Message-ID: <8607302323.AA13783@ucbvax.Berkeley.EDU> Date: Wed, 30-Jul-86 18:25:24 EDT Article-I.D.: ucbvax.8607302323.AA13783 Posted: Wed Jul 30 18:25:24 1986 Date-Received: Thu, 31-Jul-86 17:45:07 EDT References: <8607211628.AA13382@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: glacier!jbn (John B. Nagle) Organization: Stanford University, IC Laboratory Lines: 53 Approved: tcp-ip@sri-nic.arpa 1. If you are losing packets due to having too few receiving buffers in your Ethernet controller, get a modern Ethernet controller. The worst known offender is the old 3COM Multibus Ethernet controller used in early SUN systems; not only does it have only two receiving buffers, it has no overrun detection, and thus the software never tallies the many packets it tends to lose. 2. If you are losing packets due to congestion problems in a TCP-based system, this can be fixed; see my various RFCs on the subject. "Improving" the protocol by adding extra acknowledgements or fancier retransmission schemes is NOT the answer. I've developed some workable solutions that are documented in RFCs and implemented in 4.3BSD. 3. The real need for link-level acknowledges, or at least some indication of non-delivery that works most of the time, is for routing around faults. Ethernets transmit happily into black holes; when the destination dies, the source never knows. When the destination Ethernet node is a gateway, and said gateway goes down, there is no low-level way for the sending Ethernet node to notice this and divert to an alternate gateway. This is a serious problem in hi-rel systems, because we have no standard way for a host on a multi-gateway Ethernet to behave which will cause it to divert from one gateway to another when one gateway fails. There are a number of approaches to this problem, all of them lousy: - Ignore it and put up with at least minutes and perhaps indefinite downtime when a supposedly redundant gateway fails. (Considered unacceptable in military systems) - Shorten the ARP timeout to 10 seconds or so and spend excessive resources sending ARPs. (Tends to cause one retransmit every 10 seconds due to non-clever ARP implementations). - Let the hosts participate in some kind of nonstandard routing protocol so they can tell when a gateway dies. (No good for off-the-shelf hosts). - Let the transport layer inform the datagram layer when a retransmit occurs, so that the datagram layer can trigger the selection of a different gateway; if this causes selection of an up but ill-chosen gateway, a redirect from that gateway corrects the situation. (Some code to do this is in 4.2BSD, but it wasn't fully implemented.) It's all so much easier if you have link-level failure-to deliver indications. John Nagle ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986073108400000> Received: from navajo.stanford.edu by SRI-NIC.ARPA with TCP; Thu 31 Jul 86 15:42:49-PDT Received: by navajo.stanford.edu; Thu, 31 Jul 86 15:40:21 PDT Date: 31 Jul 1986 1540-PDT (Thursday) From: Jeff Mogul To: bjp@mitre-bedford.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: Mysterious ARP behavior on a tcp-ip ethernet In-Reply-To: bjp@mitre-bedford.ARPA / Thu, 31 Jul 86 15:32:00 -0500. <8607311932.AA09122@mitre-bedford.ARPA> [To summarize bjp's problem: he's got hosts sending out ARPs asking for the hardware address of IP host 192.12.120.255, and he wants to know why a host would ARP for what is supposed to be a broadcast address.] Your problem is that you have two groups of hosts with different ideas about what a broadcast address is. One group follows RFC919 and uses "all ones" for broadcast; these are the "good hosts". The other group uses the "all zeros" address that Berkeley put into 4.2BSD; these are the "bad hosts". [Note that 4.3BSD is "good".] "Good hosts" know that there are bad hosts out there and recognize, but never transmit, all-zeros broadcasts; that is why they are not trying to ARP the 192.12.120.0 address that the bad hosts are probably broadcasting to. So, what you should do is determine which of your hosts are "bad" (any host that sends an ARP request for 192.12.120.255 is bad; you might have others.) Then, call up the manufacturers and demand that they fix their code to conform to RFC919. If you are running 4.2BSD on a Vax, switch to 4.3BSD. Whatever you do, NEVER EVER modify ARP code to respond to requests for what turns out to be a broadcast address. Ever. Never, ever. Not "hardly ever"; never. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607312114.AA29772%40utah-cs.ARPA] <1986073113142300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cetron@UTAH-CS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Directory manipulation support in server FTP's Message-ID: <8607312114.AA29772@utah-cs.ARPA> Date: Thu, 31-Jul-86 17:14:23 EDT Article-I.D.: utah-cs.8607312114.AA29772 Posted: Thu Jul 31 17:14:23 1986 Date-Received: Fri, 1-Aug-86 03:11:51 EDT References: <8607301948.AA29153@ACC-SB-UNIX.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: utah-cs!cetron (Edward J Cetron) Organization: Center for Engineering Design, Univ of Utah Lines: 6 Approved: tcp-ip@sri-nic.arpa i just checked my 4.3 bsd ftp/ftpd and apparently they both support MKD, PWD, RMD, CDUP as well as their X equivalents: XMKD, XPWD, XRMD, and XCUP.... cheers -ed ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8608010033.AA06672%40ucbvax.Berkeley.EDU] <1986073114400000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mogul@NAVAJO.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Mysterious ARP behavior on a tcp-ip ethernet Message-ID: <8608010033.AA06672@ucbvax.Berkeley.EDU> Date: Thu, 31-Jul-86 18:40:00 EDT Article-I.D.: ucbvax.8608010033.AA06672 Posted: Thu Jul 31 18:40:00 1986 Date-Received: Fri, 1-Aug-86 03:12:53 EDT References: <8607311932.AA09122@mitre-bedford.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa [To summarize bjp's problem: he's got hosts sending out ARPs asking for the hardware address of IP host 192.12.120.255, and he wants to know why a host would ARP for what is supposed to be a broadcast address.] Your problem is that you have two groups of hosts with different ideas about what a broadcast address is. One group follows RFC919 and uses "all ones" for broadcast; these are the "good hosts". The other group uses the "all zeros" address that Berkeley put into 4.2BSD; these are the "bad hosts". [Note that 4.3BSD is "good".] "Good hosts" know that there are bad hosts out there and recognize, but never transmit, all-zeros broadcasts; that is why they are not trying to ARP the 192.12.120.0 address that the bad hosts are probably broadcasting to. So, what you should do is determine which of your hosts are "bad" (any host that sends an ARP request for 192.12.120.255 is bad; you might have others.) Then, call up the manufacturers and demand that they fix their code to conform to RFC919. If you are running 4.2BSD on a Vax, switch to 4.3BSD. Whatever you do, NEVER EVER modify ARP code to respond to requests for what turns out to be a broadcast address. Ever. Never, ever. Not "hardly ever"; never. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607311932.AA09122%40mitre-bedford.ARPA] <1986073120081600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bjp@MITRE-BEDFORD.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Mysterious ARP behavior on a tcp-ip ethernet Message-ID: <8607311932.AA09122@mitre-bedford.ARPA> Date: Fri, 1-Aug-86 00:08:16 EDT Article-I.D.: mitre-be.8607311932.AA09122 Posted: Fri Aug 1 00:08:16 1986 Date-Received: Fri, 1-Aug-86 08:41:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 39 Approved: tcp-ip@sri-nic.arpa I am looking to see if anyone out there can give me some information on what might be going on with our network. We have a 500 meter ethernet cable hooking together several sun workstations, a pc, a couple of Celerities, random other machines, an appletek bridge that gets us to a broadband cable with much else on it. TCP/IP are the networking protocols used and arp is used for address translation of IP internet addresses to 48 bit ethernet addresses. Some folks noticed bursts of ethernet broadcast messages recieved by an IBM PC that occured at intervals sometimes 15 seconds, sometimes 1 minute appart. I took a nutcracker and examined the traffic and took samples of the traffic including bursts of broadcast packets. I captured 128 octet slices of each packet in the traffic sample. I disassembled the hex codes to identify MAC frame fields and their contents, including the data field where I found either ip header info, or arp header info. Here is what I found. There were about 30 packets in each burst. Each was an arp request packet sent by a particular host looking for the ethernet address for 192.12.120.255 (255 is a reserved assigned number when in the host field means all hosts on 192.12.120, which is our network, mitre-b-net). This looked absurd - arp broadcasting to seek the ethernet address of what looked to me like an Internet style broadcast address for our network. Without fail this burst of arp mischief was preceded with an ethernet broadcast packet with an ip packet in its data field whose source address was either one of two guilty hosts and whose destination address was 192.12.120.255. One of the hosts is our gateway to the arpanet, milnet and many other wonderful places in the world. The plot thickens. I examined the translation tables on several hosts and found the internet address 192.12.120.255 with a big ? where an ethernet address would have been if arp had a sensible internet address for a specific target host to work with. Does anyone know why IP would do such a thing. Is this how IP forwards? If this is legitimate forwarding then why do arps do silly things with it? bj Pease ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12227241581.31.HEDRICK%40RED.RUTGERS.EDU] <1986073121240200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HEDRICK@RED.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Mysterious ARP behavior on a tcp-ip ethernet Message-ID: <12227241581.31.HEDRICK@RED.RUTGERS.EDU> Date: Fri, 1-Aug-86 01:24:02 EDT Article-I.D.: RED.12227241581.31.HEDRICK Posted: Fri Aug 1 01:24:02 1986 Date-Received: Fri, 1-Aug-86 08:36:07 EDT References: <8607311932.AA09122@mitre-bedford.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 60 Approved: tcp-ip@sri-nic.arpa It is fairly common to get large-scale ARP'ing when there are confusions on your network about hosts. In general, I agree with Jeff Mogul. However this is common enough that I'd like to add a bit of detail. I also have some suggestions to allow you to improve things without getting every vendor to fix their implementation immediately. First, let's get clear about what is happening. One of your hosts is sending a broadcast. Since your network number is apparently 192.12.120, it is using 192.12.120.255. This is the new standard: To make a broadcast address, stick all ones in the host field. (255 is all ones.) Unfortunately, you have hosts on your network that believe that a broadcast address should be made by sticking a zero in the host field, i.e. 192.12.120.0. When they see the packet addressed to 192.12.120.255, they think you are trying to address some specific host with that address. Since they are not that host, they decide to be nice and forward the packet to the host. In order to forward the packet, they need the Ethernet address of 192.12.120.255. Thus they issue an ARP request for it. The entry in the ARP table marked with ? means that they have issued an ARP request but not yet gotten a response. In my opinion, the simplest solution is to continue using the old convention on all machines until the new convention has been implemented everywhere. As Jeff points out, new implementations are being designed to accept either. Most new implementations allow you to set the broadcast address that they will emit. So my suggestion is that you try to get up to date implementations as soon as possible, but until you do, set all the new implementations to use 192.12.120.0 as their broadcast address. Once everything is updated, then change over to using the new convention on all your machines. There is one more point. It is really a mistake for normal machines to forward packets that are intended for other machines. This is happening because almost every IP implementation has the potential for acting as a gateway between two networks. Such a gateway is expected to forward packets from one network to the other. Most of the code simply checks to see whether the packet is for it, and if not, sends it on to the destination. This isn't a terribly clever approach, and real gateways are generally more careful. But when your machines isn't acting as a gateway, forwarding packets at all is a bad idea. It can gain nothing, and when confusion occurs, things like you observed happen. Most implementations allow you to disable this forwarding. In 4.2, you simply set a variable ipforwarding to 0. This can be done in adb even if you don't have source. Even this isn't ideal, because your machine will send an error message back to the source of the packet telling it that the packet couldn't be delivered. We disable forwarding more drastically. In routine ip_forward, we simply discard the packet. (There is a test at the beginning of the routine checking whther the packet is a broadcast. If so, it is thrown away. Just make that test always succeeed.) But even if you don't do this, turning off ipforwarding will be a big help. Every time the system sees a stray packet, it will send back an error to the sender, rather than issuing an ARP. An ARP is a broadcast, so it clogs up everybody. The error will just clog up the guy who is causing the problem. Note, by the way, that the Applitek bridge in effect turns the whole set of Ethernets that it connects into a single logical Ethernet. Depending upon how you have allocated Internet addresses, you may hve to make sure that every host on every Ethernet connected via the Applitek system is doing things consistently. ------- ----MESSAGE-END----