|
|
ARCHIVE: TCP-IP Distribution List - Archives (1986)
DOCUMENT: TCP-IP Distribution List for July 1986 (127 messages, 76263 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1986/07.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Jul-86 07:06:32 EDT From: dardy@NRL-CSS.ARPA (Hank Dardy) To: mod.protocols.tcp-ip Subject: Re: Am I imagining things?
We see the same behavior here. Haven't figured out cause. Hank
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Jul-86 09:00:29 EDT From: brescia@BBNCCV.ARPA (Mike Brescia) To: mod.protocols.tcp-ip Subject: Re: Am I imagining things?
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
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Jul-86 22:49:58 EDT From: hes@ecsvax.UUCP (Henry Schaffer) To: mod.protocols.tcp-ip Subject: Reading List?
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)
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Jul-86 23:25:35 EDT From: eichelbe@NADC To: mod.protocols.tcp-ip Subject: NIC host table changes - how to survive?
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
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Jul-86 13:09:38 EDT From: wales@LOCUS.UCLA.EDU (Rich Wales) To: mod.protocols.tcp-ip Subject: Re: NIC host table changes - how to survive?
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."
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Jul-86 20:23:50 EDT From: sjl@amdahl.UUCP.UUCP To: mod.protocols.tcp-ip Subject: IEEE 802 and ISO
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 <insert favorite hot
> 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. ]
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Jul-86 01:31:26 EDT From: mills@DCN6.ARPA To: mod.protocols.tcp-ip Subject: Sources for radio clocks
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 -------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Sun, 6-Jul-86 12:58:24 EDT From: BEAME@MCMASTER.BITNET.UUCP To: mod.protocols.tcp-ip Subject: An out of the blue query.
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
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Sun, 6-Jul-86 16:42:47 EDT From: MILLS@D.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: An out of the blue query.
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 -------
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Jul-86 01:54:17 EDT From: mills@DCN6.ARPA To: mod.protocols.tcp-ip Subject: On routing freedom and statutes of liberty -or- Ether is a gas
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
-------
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Jul-86 11:09:37 EDT From: mills@DCN6.ARPA To: mod.protocols.tcp-ip Subject: Clarification on access control
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 -------
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Jul-86 11:39:52 EDT From: JED@CS.COLUMBIA.EDU (Jed Schwartz) To: mod.protocols.tcp-ip Subject: please remove me from tcp-ip mailing list
-------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Jul-86 17:51:18 EDT From: bjp@MITRE-BEDFORD.ARPA.UUCP To: mod.protocols.tcp-ip Subject: The availability of the host, ulana
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
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Jul-86 18:07:26 EDT From: leong@ANDREW.CMU.EDU (John Leong) To: mod.protocols.tcp-ip Subject: Re: Re: IEEE and Ethernet
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
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Jul-86 18:19:00 EDT From: mogul@SU-NAVAJO.ARPA (Jeff Mogul) To: mod.protocols.tcp-ip Subject: Re: On routing freedom [address masks]
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
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Jul-86 19:47:14 EDT From: leong@ANDREW.CMU.EDU (John Leong) To: mod.protocols.tcp-ip Subject: Re: IEEE 802 and ISO
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
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Jul-86 23:40:53 EDT From: eric@MONET.BERKELEY.EDU (Eric Allman) To: mod.protocols.tcp-ip Subject: Re: failed mail from DCP
Re: > Date: Mon, 30 Jun 86 09:42 EDT > From: Joseph R Goldstone <joseph@sapsucker.scrc.symbolics.com> > 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
-----------[000017][next][prev][last][first]----------------------------------------------------
Date: Mon, 7-Jul-86 23:41:23 EDT
From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To: mod.protocols.tcp-ip
Subject: Re: Re: IEEE and EthernetHow 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 -------
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Jul-86 09:30:21 EDT From: mckenzie@J.BBN.COM (Alex McKenzie) To: mod.protocols.tcp-ip Subject: DoD Representation at ISO
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
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Jul-86 18:40:36 EDT From: leong@ANDREW.CMU.EDU (John Leong) To: mod.protocols.tcp-ip Subject: Re: Re: IEEE and Ethernet
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
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Jul-86 20:48:56 EDT From: REINER%November%ti-csl.CSNET@CSNET-RELAY.ARPA To: mod.protocols.tcp-ip Subject: RFC950
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
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 1986 11:23:45 PDT From: POSTEL@B.ISI.EDU To: TCP-IP@SRI-NIC.ARPA Subject: re: RFC-950
Lisa Reiner: See the last two lines of RFC-950, that is Appendix IV on page 17. AM1 = 17 and AM2 = 18. --jon. -------
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Jul-86 11:45:30 EDT From: leiner@RIACS.ARPA To: mod.protocols.tcp-ip Subject: Re: IEEE 802 and ISO
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 ----------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Jul-86 11:55:04 EDT From: MILLS@D.ISI.EDU To: mod.protocols.tcp-ip Subject: Re: RFC950
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 -------
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Jul-86 12:33:05 EDT From: leong@ANDREW.CMU.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO
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
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Jul-86 14:23:45 EDT From: POSTEL@B.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: re: RFC-950
Lisa Reiner: See the last two lines of RFC-950, that is Appendix IV on page 17. AM1 = 17 and AM2 = 18. --jon. -------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Jul-86 14:26:15 EDT From: braden@VENERA.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Installing tn3270
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
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Jul-86 14:43:13 EDT From: mckenzie@J.BBN.COM (Alex McKenzie) To: mod.protocols.tcp-ip 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".
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 Jul 86 14:43:13 EDT From: Alex McKenzie <mckenzie@j.bbn.com> To: John Leong <leong@andrew.cmu.edu> 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".
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Jul-86 16:28:00 EDT From: DDEUTSCH@A.BBN.COM To: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO
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
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Jul-86 18:30:19 EDT From: leong@ANDREW.CMU.EDU (John Leong) To: mod.protocols.tcp-ip Subject: TCP/IP and Internation standard
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.
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 Jul 1986 22:01 CDT From: Phil Howard <PHIL%UIUCVMD.BITNET@WISCVM.ARPA> To: TCP/IP Group <TCP-IP@SRI-NIC.ARPA> , MAIL working group list <MAIL-L%BITNIC.BITNET@WISCVM.ARPA> Subject: "restricted standards"
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.
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Jul-86 23:01:00 EDT From: PHIL@UIUCVMD.BITNET (Phil Howard) To: mod.protocols.tcp-ip Subject: "restricted standards"
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.
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Jul-86 23:14:22 EDT From: mrose@nrtc-gremlin (Marshall Rose) To: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO
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
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Thu, 10-Jul-86 03:11:14 EDT From: stef@nrtc-gremlin (Einar Stefferud) To: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO
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
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Thu 10 Jul 86 11:37:33-PDT From: "Rick Jones" <jones@nrl-lcp> To: "tcp-ip" <tcp-ip@sri-nic> Subject: software...
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 ------
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Thu, 10-Jul-86 10:04:25 EDT From: tcs@USNA.ARPA (Terry Slattery) To: mod.protocols.tcp-ip 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
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Jul 86 10:04:25 EDT From: Terry Slattery <tcs@USNA.ARPA> 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
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Thu, 10-Jul-86 12:57:15 EDT From: mrose@nrtc-gremlin (Marshall Rose) To: mod.protocols.tcp-ip Subject: Re: POP for dumb workstations
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 <list of hosts to try>". 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
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Thu, 10-Jul-86 13:29:41 EDT From: jnc@BRUBECK.PROTEON.COM.UUCP To: mod.protocols.tcp-ip Subject: Hosts forwarding packets
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 -------
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Jul 86 13:29:41 EDT From: jnc@brubeck.proteon.com To: tcp-ip@nic Cc: bug-cgw,bug-lispm@ai.ai.mit.edu,jnc Subject: Hosts forwarding packets
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 -------
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Thu, 10-Jul-86 14:13:47 EDT From: OLE@SRI-NIC.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Vendors Guide Update
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. -------
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Thu, 10-Jul-86 15:33:00 EDT From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) To: mod.protocols.tcp-ip Subject: Re: Lisp machines don't receive network level broadcasts right, causing net mayhem
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.
-------
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Thu, 10-Jul-86 15:34:00 EDT From: DDEUTSCH@A.BBN.COM.UUCP To: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO
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?
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 1986 15:34-EDT From: DDEUTSCH@A.BBN.COM To: mrose@NRTC-GREMLIN.ARPA Cc: DDEUTSCH@A.BBN.COM, leong@ANDREW.CMU.EDU mckenzie@J.BBN.COM, tcp-ip@SRI-NIC.ARPA Subject: Re: DoD Representation at ISO
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?
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Thu, 10-Jul-86 18:21:12 EDT From: jones@nrl-lcp.UUCP To: mod.protocols.tcp-ip Subject: software...
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 ------
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Thu, 10-Jul-86 23:16:06 EDT From: MILLS@D.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Hosts forwarding packets
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 -------
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 1986 23:16:06 EDT From: MILLS@D.ISI.EDU To: jnc@BRUBECK.PROTEON.COM, tcp-ip@SRI-NIC.ARPA Cc: bug-cgw@BRUBECK.PROTEON.COM, bug-lispm@AI.AI.MIT.EDU, MILLS@D.ISI.EDU Subject: Re: Hosts forwarding packets
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 -------
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Fri, 11-Jul-86 03:29:14 EDT From: mrose@nrtc-gremlin.UUCP To: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO
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
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Fri, 11-Jul-86 05:48:40 EDT From: sjl@amdahl.UUCP.UUCP To: mod.protocols.tcp-ip Subject: ISO Standards and the Internet
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. ]
-----------[000050][next][prev][last][first]---------------------------------------------------- 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
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Fri, 11-Jul-86 07:37:00 EDT From: CERF@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO
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
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 1986 07:37-EDT From: CERF@A.ISI.EDU To: DDEUTSCH@BBNA.ARPA Cc: mrose@NRTC-GREMLIN.ARPA, leong@ANDREW.CMU.EDU mckenzie@J.BBN.COM, tcp-ip@SRI-NIC.ARPA Subject: Re: DoD Representation at ISO
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
-----------[000053][next][prev][last][first]---------------------------------------------------- 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 :-]
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Fri, 11-Jul-86 12:01:02 EDT From: root@BU-CS.BU.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Installing tn3270
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
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Fri, 11-Jul-86 12:02:00 EDT From: JOHNSON%northeastern.edu@CSNET-RELAY.ARPA.UUCP To: mod.protocols.tcp-ip 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 :-]
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Fri, 11-Jul-86 12:19:48 EDT From: STGEORGE@UNMB.BITNET.UUCP To: mod.protocols.tcp-ip Subject: BITNET mail follows
SEND TCP-IP-IMPLEMENTATIONS.TXT
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Fri, 11-Jul-86 15:34:17 EDT From: leong@ANDREW.CMU.EDU.UUCP To: mod.protocols.tcp-ip Subject: ODA - New ISO standard in the working
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
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 1986 19:12:35 PDT From: POSTEL@B.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Subject: re: POP for Dumb Workstations
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. -------
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Fri, 11-Jul-86 18:58:06 EDT From: ROMKEY@XX.LCS.MIT.EDU.UUCP To: mod.proto