The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

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 Ethernet


	How do you do address translation? I.e. where does the code that
creates the LLC header get the 48 bit address from to go with a 32 bit
IP address?		Noel
-------

-----------[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.protocols.tcp-ip
Subject:   Re: POP for dumb workstations

> No SMTP process runs on the workstation. The workstations that we're
> thinking about are the smaller workstations (SGI Iris, IBM-PC, etc).

Just a bit of information: FTP Software's latest release has an SMTP
server and client for the PC...

John Romkey			FTP Software, Inc.
(617) 868-4878			PO Box 150
UUCP: romkey@mit-vax.UUCP	Kendall Square Branch
ARPA: romkey@xx.lcs.mit.edu	Boston, MA, 02142
-------

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11-Jul-86 22:12:35 EDT
From:      POSTEL@B.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
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.
-------

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Jul-86 05:47:44 EDT
From:      gds@SRI-SPAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Am I imagining things?

In article <8606302206.AA07389@nrl-aic>, hemphill@NRL-AIC.ARPA (Gavin Hemphill) writes:
> 
> 	Sorry about the previous empty message -- fumble fingers strikes again.
> 
> 	Is it my imagination or are other people experiencing problems as
> well.  I have noticed lately that I can't FTP files bigger than 20 or 30 KB.
> The symptoms are that after 6 or 7 minutes (clock time) the FTP connections
> (to wherever from nrl-aic) break, there are no messages or indications from
> the remote server just the "ftp>" prompt.  Secondary to this when I try to
> open a new connection to the same host I'll get the "host unreachable" 
> message, but if I telnet to any other host -- and from there FTP or telnet 
> to my original destination I can get through, and after backing out of that 
> a direct FTP will again get through.  Anybody else had similar problems?  If 
> so, any pointers would be appreciated.
> 	G++

Sounds like a couple of problems.  The "host unreachable" message could be
caused, if you are talking to an imp, by the bug in the imp driver that
causes a destination host to be marked down because no packets can be deliv-
ered to it.  This can be fixed by changing the value of HOSTTIMER in
/sys/netimp/if_imp.h from 128 to a smaller number (I used 1 instead of 0
because our imp was crashing and I did not want to deliver packets too
quickly to it).

The ftp lockup problems sound like the "bad file number" problems we were
having a few months ago and a related problem with getting "connection
error" messages telnetting from a tiu on a prnet to a vax on the arpanet.
I discovered that the connection errors were coming when a gateway from
the arpanet to the prnet was having trouble fragmenting a packet of odd
byte length > 254.  By changing the arpanet mtu on the vax from 982 (act-
ually arpanet-pli mtu) to 254 the problem went away.  Likewise, many of
our bad file number and ftp lockup problems went away when I had the
ethernet mtu changed from 1500 to 576.

Next time this happens try and figure out to where you were trying to con-
nect, and what (if any) gateways you had to go through to get there.  If
possible, monitor the tcp connection looking for a reset (by doing netstats
this will show as a connection going from ESTABLISHED to not showing up at
all).  If you can turn on tcp debugging, look for a RST packet coming in.

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Jul-86 20:15:28 EDT
From:      gnu@hoptoad.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Getting machine readable copies of protocol specs

Good luck at this.  The problem is that the national standards
organizations make money by selling copies of these standards.  They
will not let the technical committees just post them to the net or drop
them somewhere for anonymous FTP.  This has been an ongoing problem in
the ANSI C standardization effort.  Happily the IEEE P1003 committee
developing a standard for "portable operating systems" (they can't call
it Unix(TM)) is in favor of electronic media and has been making drafts
and discussion available on the net.

I suspect the difference is because the IEEE is answerable to its
members, while ANSI is answerable to nobody.

PS:  I was a member of the ANSI/ISO APL language standards committee
and it's true that designing a standard by committee is a different job
than building a working system/network/etc.  The APL committee took
pains to seldom engage in "design", but to just adopt the best and most
compatible things from a variety of implementations, inventing new
ideas only when required to make everything consistent.  Looking from
the outside, it seems like the ISO standards folks are building a lot
of paper designs that aren't implemented until after the standard is
approved.  Anyone who ever tried to write a program from its specs,
without revising the specs based on what was learned during
implementation, will recognize the problems in this.

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13-Jul-86 10:58:13 EDT
From:      milazzo@rice.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"

Barry:

The 3270 support I wrote for telnet is NOT "a version of tn3270".  I
wrote the original version of the code long before hearing of tn3270,
and possibly before tn3270 was written.  I have never seen any version
of tn3270.

My code examines the user's terminal type and chooses the largest
suitable screen size from the following list:  3278-5, 3278-4, 3278-3,
3278-2, 3278-1, 3277-1.  If the user's terminal is not a CRT or is too
small for any of these terminal types, telnet simply remains in NVT
mode.  If the user's terminal is an oddly-shaped window, such as on a
SUN, telnet uses the appropriate upper left portion of the window.  On
startup it assumes the default size for the chosen 3270 model, and
switches to the alternate size upon receipt of an EWA.

My code currently does not support SNA codes, negotiation back to NVT
mode, or light pens.  It incompletely implements the PT order, and has
problems with SYS REQ, though the last may be WISCNET's fault, not mine.
SNA codes and negotiation back to NVT mode are trivial fixes.  The
remainder present varying degrees of difficulty.  PEN SELECT would be
easy to add, but real light pen support (say with the mouse on a SUN)
is fairly difficult.

				Paul G. Milazzo
				Dept. of Computer Science
				Rice University, Houston, TX

Domain:	milazzo@rice.EDU, milazzo@rice.ARPA
BITNET:	milazzo@ricenet
UUCP:	{cbosgd,convex,hp-pcd,sun,waltz}!rice!milazzo

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13-Jul-86 12:57:55 EDT
From:      root@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Installing tn3270

Apologies for any misunderstanding, I knew that Paul's code
was not derivitive of the tn3270 code, I was using the term
generically ("a version of tn3270".) I only meant to bring out
that not only can various 327x's be supported via subnegotiation,
it's even been done (by Paul) and it works.

	-Barry Shein, Boston University

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13-Jul-86 22:54:26 EDT
From:      roy@phri.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Fuzzball hosts -- the summary


	Some time ago I asked what a fuzzball host was.  What follows is a
condensation of the responses I got.  Thanks to everybody who took the time
to reply.  Due to my eclectic filing system, this is not in any particular
order, chronological or otherwise.

------------

Date: Wed, 18 Jun 86 13:46:28 EDT
From: Mike O'Connor <allegra!seismo!trantor.UMD.EDU!oconnor>

Roy,
	Here is Dave's reply to the forwarding of my description of the
origin of the term Fuzzball. [...]  BTW, the seismo people use one of
Dave's fuzzballs (dcn1) for clock synchronization.

	Date: 18 Jun 1986 12:52:28 EDT
	From: MILLS@USC-ISID.ARPA
	Subject: Re: Official Derivation of the term "Fuzzball"
	To: oconnor

	Fuzzball gateways are now in place in the NSF Backbone net, as well
	as the USAN (university consortium) net, both creatures of NSF. Add
	NASA, CMU and CNUCE (Italy) to your list. Mention that the fuzz
	were developed as research tools and intended for application in
	protocol development, prototype testing and performance evaluation,
	but have also found temporary application in specialized
	environments with unusually difficult network routing and
	management requirements, with the expectation that the vendor
	community will eventually develop commercial devices that satisfy
	these requirements.

	As an aside, the Ethernets of nine universities are now combined
	(you got it) on the USAN satellite channel. The rwhos are simply
	glorious. The fuzzies got very clever very quick

	Dave

----------------

Date: Thu 19 Jun 86 23:49:44-EDT
From: "J. Noel Chiappa" <cmcl2!seismo!XX.LCS.MIT.EDU!JNC>
Subject: Re: Fuzzball hosts
To: phri!roy

	"Fuzzball" is the name of the software package for the DEC PDP11
written primarily by Dave Mills, MILLS@ISI. It evolved from the DEC RT-11
operating system, but is somewhat more complex by now. It contains a full
set of TCP/IP software, and can function as a user or server host and also
as a gateway.

	Noel

----------------

Date: Wed, 18 Jun 86 21:23:23 edt
From: Henry Schaffer <cmcl2!seismo!mcnc.CSNET!ecsvax!hes>
To: phri!roy
Subject: Re: Fuzzball hosts

This is a tcp-ip router consisting of code written by Dave Mills??  at U.
Md. which runs on a PDP-11.  I don't know the origin of the name.

----------------

Date: Thu, 19 Jun 86 19:37:36 CST
From: Stan Barber <cmcl2!seismo!drillsys!soma!sob>
To: roy@phri.uucp
Subject: Re: Fuzzball hosts

A "fuzzball" is a PDP-11/23 or PDP-11/73 running as a dedicated gateway or
providing a network (i.e. internet) service (like the correct time).  Their
inventor gave them that name for an unknow reason. Currently, the TCP-IP
implementation guide sez that fuzzballs are available from M/A-COM
Link-a-bit. A friend of mine there never heard of them.  Hope this helps.

----------------

Date: Mon, 16 Jun 86 13:29:44 EDT
From: Mike O'Connor <allegra!seismo!trantor.UMD.EDU!oconnor>
To: allegra!phri!roy
Subject: Re:  Fuzzball hosts

Roy,
	In case Dave Mills doesn't answer I'll give you some details.

	Dave Mills (currently with M/A-Com Linkabit) has a software package
(really an Operating System) that emulates Dec's Rt-11 but includes full
Arpanet protocol suite.  It mostly runs on LSI-11's but some people have a
version running on some PDP-11s.

	A few years back ('80 | '81?) at a meeting at DARPA headquarters,
someone used the term "fuzzball" to describe Dave's system.  Most of the
other people were TOPS-20 users with maybe one UNIX user.  While intended
as a somewhat derogatory term Dave embraced it and has used it to describe
his system ever since.  I'm not even sure he remembers the origin.

	A more detailed description of the Fuzzball system can be found at
the NIC in the file describing tcp-ip implementations.  There were also a
couple of RFC's concerning Dave's system.

	BTW, the last I heard "Fuzzballs" were going to be used as gateways
on the NSFnet.  They can be found at the University of Md., University of
Michigan, Ford-Aerospace, and quite a few places in Europe.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jul 86 14:51:16 -0500
From:      bjp@mitre-bedford.ARPA
To:        tcp-ip@sri-nic.ARPA
Subject:   ULANA Specifications once again available

Appologies for the interuption.  This letter is in regards to a previous
announcement, that due to circumstances beyond my control, I had to move
the ftp location for the Ulana Specifications.  For the few stagglers who
may not have gotten copies yet.  A copy is once again available:

		address:	mitre-b-ulana.arpa
		user:		guest
		password:	anonymous
		pathname:	/usr/users/guest/ulana.specs


					bj Pease
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Jul-86 20:46:37 EDT
From:      bjp@MITRE-BEDFORD.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   ULANA Specifications once again available


Appologies for the interuption.  This letter is in regards to a previous
announcement, that due to circumstances beyond my control, I had to move
the ftp location for the Ulana Specifications.  For the few stagglers who
may not have gotten copies yet.  A copy is once again available:

		address:	mitre-b-ulana.arpa
		user:		guest
		password:	anonymous
		pathname:	/usr/users/guest/ulana.specs


					bj Pease

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Jul-86 23:27:31 EDT
From:      atkins@nbires.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Ways to input your X.400/MOTIS concerns

The Corporation for Open Systems (COS) is an excellent conduit for input to the 
international standards bodies, but it is rather expensive.  There is the 
membership fee, plus the additional cost of participation.  (It was said by 
a COS member that COS is not looking for many members of little commitment, 
but a lesser number of members of great commitment.)

There is another, perhaps less direct, input into the ISO/CCITT bodies.
NBS has an OSI Workshop which is producing a document entitled "Implementation
Agreements Among Implementors of OSI Protocols", which provides a somewhat 
more precise interpretation of the various OSI standards, namely FTAM and 
X.400 (in addition to the lower layers).

Production of significant portions of this document fall into the hands
of SIGs (Special Interest Groups).  Participation in these SIGs is "limited"
to Implementors, Vendors, and Users of OSI protocols.  As you can see, anyone
can take part in this process.  Many active SIG members are also members 
of CCITT and ISO, and can thus provide SIG input back into the
standards process.

NBS out of Gaithersburg, MD can provide information on these workshops and
SIG participation.  Since these SIGs are populated by people doing the work,
many of the real problems are brought out into the open.  I can speak from
experience, there is a high degree of commitment among the participants (in 
the X.400 SIG at least).

So if you want "be part of the solution" rather than complain about the past,
here is an opportunity.

Brian Atkins   ...{attunix, hao, allegra, ucbvax}!nbires!atkins
NBI Inc., P.O. Box 9001, Boulder CO 80301	(303) 444-5710

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Jul-86 09:42:52 EDT
From:      jsq@SALLY.UTEXAS.EDU (John Quarterman)
To:        mod.protocols.tcp-ip
Subject:   Re:  Getting machine readable copies of protocol specs

Brief elaboration on certain points of John Gilmore's message:

The X3J11 C Committee (they hate being called ANSI C) has a USENET
newsgroup called mod.std.c.  It does not appear to be gatewayed to any
Internet mailing list.  Doubtless the moderator of that newsgroup
<std-c@cbosgd.att.com> could elaborate.  (The mailing list
INFO-C@BRL.ARPA is gatewayed to the different newsgroup net.lang.c.)

The IEEE 1003 Portable Operating System for Computer Environments Committee
indirectly sponsors the USENET newsgroup mod.std.unix (known in the Internet
as the mailing list STD-UNIX@SALLY.UTEXAS.EDU) and many of the committee
members read it.  I'm the moderator and have in the past made on-line
copies of drafts of the standard available by anonymous FTP from sally
in cooperation with the rest of the committee.

The current document is the published Trial Use Standard and is not
available on-line, though future drafts probably will be.  Actually,
according to IEE what is on-line is something that "represents" the draft:
the real draft is the paper copy, which you can also get just by
getting on a paper mailing list.

For details on access to these committees and standards, see recent
articles in mod.std.unix, whose archives may be gotten by anonymous FTP
from sally.utexas.edu.  The current volume is in /pub/mod.std.unix.

PS:  IEEE 1003.1 is working on adoption by ISO.  We'll see how that
affects availability of drafts.

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Jul-86 11:33:27 EDT
From:      eichelbe@NADC.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP/IP for CDC?

I have looked at the TCP-IP-IMPLEMEMTATIONS.TXT file available from
SRI-NIC, and I have not seen any way for a CDC Cyber computer to hook
up and send/receive Internet mail without the aid of a VAX 11/780 as a
front-end.  Is there anyone out there who *presently* has some TCP/IP
implemetation other than those mentioned in the above-stated document?
We don't want to have to wait until February, 1987, for CDC to come out
with its product.  Any info/leads would be greatly appreciated.

Please respond directly to me unless what you have to say is of general
interest.

		Thank you,
			Jon Eichelberger
			eichelbe@NADC.ARPA

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 1986 11:33:27-EDT
From:      eichelbe@NADC
To:        info-unix@brl, tcp-ip@sri-nic, unix-wizards@brl
Subject:   TCP/IP for CDC?
I have looked at the TCP-IP-IMPLEMEMTATIONS.TXT file available from
SRI-NIC, and I have not seen any way for a CDC Cyber computer to hook
up and send/receive Internet mail without the aid of a VAX 11/780 as a
front-end.  Is there anyone out there who *presently* has some TCP/IP
implemetation other than those mentioned in the above-stated document?
We don't want to have to wait until February, 1987, for CDC to come out
with its product.  Any info/leads would be greatly appreciated.

Please respond directly to me unless what you have to say is of general
interest.

		Thank you,
			Jon Eichelberger
			eichelbe@NADC.ARPA
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jul 86 16:06:44 -0500
From:      Dennis Rockwell <dennis@SH.CS.NET>
To:        hwb@GW.UMICH.EDU
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: 127.0.0.1
Hans, everybody,

There's a bug (*not* a feature!) in the 4.2 network code that assigns the
source address of a packet to be some single IP interface on that machine
(in fact, it binds the local address too early, before the packet or
connection has been routed).  For incoming TCP connections, there is no
problem; the local address is specified by the host that initiates the
connection.  For outgoing UDP packets, the first interface in the interface
list (given by netstat -i) is usually used (although the loopback interface
{which uses 127.0.0.1 as its address} is most often the last listed
interface).

CSNET requires that X25net sites install this fix; during installation and
checkout, we most often do not tell our kernel how to reach a site's local
network.  This causes TCP connections from our new site to the Internet fail
while connections from the Internet to the new site work.

There are fixes for this available from BRL (at least, that's where I got
them).  Mike?  Are they in anonymous FTP?

Dennis Rockwell
CSNET Technical Staff
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      16-Jul-86 15:26:26-UT
From:      hwb@gw.umich.edu
To:        tcp-ip@sri-nic.arpa
Cc:        hwb@GW.UMICH.EDU
Subject:   127.0.0.1
How come I when I am resolving addresses that I am gettin domain replies
with a source address of 127.0.0.1? I think I saw that in response to
requests sent to Seismo (10.0.0.25), but may be from other's, too.
Telnet to Seimo works fine and does not use 127.0.0.1 on the way back.
I just sent domain requests specifically to Seismo, and the problem is
easily reproducable. I am posting this to this list since I am not sure
whether it was *only* Seismo or others, too.
 
	-- Hans-Werner Braun
-------
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Jul-86 10:38:59 EDT
From:      yhe@ORNL-MSR.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP/IP on Prime(PRIMOS)

Does anyone out there have experience with TCP/IP on a Prime machine using
PRIMOS?  If so, please mail direct to me a summary of your experience.

Young Etheridge, yhe@ornl-msr.arpa
Oak Ridge National Laboratory

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Jul 86 14:20:48 edt
From:      Bob Sutterfield <bob@ohio-state.ARPA>
To:        info-vax@sri-kl.arpa, tcp-ip@sri-nic.arpa
Cc:        karl-d@ohio-state.ARPA, mills@ohio-state.ARPA, summers@ohio-state.ARPA
Subject:   Tektronix TCP/IP news?
A while back, there was some discussion on either info-vax or tcp-ip about a
TCP/IP package developed at Tektronix for VMS VAXen.  There was even
proposed the creation of a discussion list, after which talk on the above
lists dropped to nil, as one might expect when traffic moves to a new list.
Unfortunately, I can't find out where the tektcp-request address is, to
inquire about progress of work on the software.

If such a discussion list hasn't been created yet, could someone involved in
the work bring me up to date?  What various hardware configurations and
versions of VMS does Tek-TCP run under?  What's involved in getting a copy
to test and play with?  Is it still `pretty much public-domain' like it was
before?  What's involved in the `pretty much' part?  Thanks for your help.
-----
Human: Bob Sutterfield
 Mail: bob%osuag.uucp@ohio-state.arpa	or: bob@ohio-state.arpa
   or: ...!cbosgd!osu-eddie!osuag!bob	or: ...!cbosgd!osu-eddie!bob
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      17-Jul-86 14:15:43-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/TIME service
Folks,

The level of TCP/TIME requests directed to our DCnet fuzzballs has escalated
to the point of serious intrusion in other services. Our DCN1.ARPA fuzzball,
for example, is also our ARPAnet gateway DCN-GATEWAY and well-known as a good
source of accurate time. The problem is that the poor horse has only two
TCP servers, ordinarily used only for casual snooping and maintenance. A
TCP/TIME transaction takes anywhere from eight to 20 seconds, depending on
the path and degree of flake involved. At the present volume of requests,
it is not unusual for both servers to be occupied, while other requestors
are flailing SYNs and congesting the buffer pool.

As the longtime browsers of this know, I have invited clockwatchers to use
UDP/TIME and NTP/TIME protocols but highly discouraged use of the TCP/TIME
protocol. Not only are the former much more accurate, but the latter is very
disruptive to our normal operations. Note that Unix daemons for UDP-based
time services are readily available. (Eeep - make that UDP/NTP, not NTP/TIME
in the above!)

Some clockwatchers are using TCP/TIME on DCnet fuzzballs other than DCN1.ARPA.
Again, be advised the other critters set their watches from DCN1.ARPA anyway,
so there is nothing to be gained except escaping detection in the logs.

At the end of the month I will review the situation. If the onslaught persists,
I may have to disable the TCP/TIME service, perhaps (following a recent suggestion)
including a random offset of amplitude maybe two days.

Dave
-------
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Jul-86 22:57:56 EDT
From:      hwb@GW.UMICH.EDU
To:        mod.protocols.tcp-ip
Subject:   127.0.0.1

How come I when I am resolving addresses that I am gettin domain replies
with a source address of 127.0.0.1? I think I saw that in response to
requests sent to Seismo (10.0.0.25), but may be from other's, too.
Telnet to Seimo works fine and does not use 127.0.0.1 on the way back.
I just sent domain requests specifically to Seismo, and the problem is
easily reproducable. I am posting this to this list since I am not sure
whether it was *only* Seismo or others, too.
 
	-- Hans-Werner Braun
-------

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Jul-86 02:55:37 EDT
From:      dennis@SH.CS.NET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: 127.0.0.1

Hans, everybody,

There's a bug (*not* a feature!) in the 4.2 network code that assigns the
source address of a packet to be some single IP interface on that machine
(in fact, it binds the local address too early, before the packet or
connection has been routed).  For incoming TCP connections, there is no
problem; the local address is specified by the host that initiates the
connection.  For outgoing UDP packets, the first interface in the interface
list (given by netstat -i) is usually used (although the loopback interface
{which uses 127.0.0.1 as its address} is most often the last listed
interface).

CSNET requires that X25net sites install this fix; during installation and
checkout, we most often do not tell our kernel how to reach a site's local
network.  This causes TCP connections from our new site to the Internet fail
while connections from the Internet to the new site work.

There are fixes for this available from BRL (at least, that's where I got
them).  Mike?  Are they in anonymous FTP?

Dennis Rockwell
CSNET Technical Staff

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Jul-86 04:18:43 EDT
From:      mills@DCN6.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP/TIME service

Folks,

The level of TCP/TIME requests directed to our DCnet fuzzballs has escalated
to the point of serious intrusion in other services. Our DCN1.ARPA fuzzball,
for example, is also our ARPAnet gateway DCN-GATEWAY and well-known as a good
source of accurate time. The problem is that the poor horse has only two
TCP servers, ordinarily used only for casual snooping and maintenance. A
TCP/TIME transaction takes anywhere from eight to 20 seconds, depending on
the path and degree of flake involved. At the present volume of requests,
it is not unusual for both servers to be occupied, while other requestors
are flailing SYNs and congesting the buffer pool.

As the longtime browsers of this know, I have invited clockwatchers to use
UDP/TIME and NTP/TIME protocols but highly discouraged use of the TCP/TIME
protocol. Not only are the former much more accurate, but the latter is very
disruptive to our normal operations. Note that Unix daemons for UDP-based
time services are readily available. (Eeep - make that UDP/NTP, not NTP/TIME
in the above!)

Some clockwatchers are using TCP/TIME on DCnet fuzzballs other than DCN1.ARPA.
Again, be advised the other critters set their watches from DCN1.ARPA anyway,
so there is nothing to be gained except escaping detection in the logs.

At the end of the month I will review the situation. If the onslaught persists,
I may have to disable the TCP/TIME service, perhaps (following a recent suggestion)
including a random offset of amplitude maybe two days.

Dave
-------

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1986 13:13:22 PDT
From:      Douglas M. Olson <dolson@ADA20.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   VAX IP/TCP
Preface:  This one got longer than I had expected.  I'd planned a
brief query to INFO-VAX for suggestions: but what this missive is
REALLY about is a newcomer to the DDN community trying to bring a new
installation aboard the net.  It is long.  I need some help.  If this
sort of thing isn't your bag, recommend you skip it!
---------
From the outside looking in, I'm having a hard time figuring out
what I'm supposed to obtain (hardware and software) to make my
VAXCluster able to communicate on the DDN using VAX-based
instantiations of TELNET, FTP, and (especially important) SMTP.  We
have just registered our connection requirement through the normal
MAJCOM and ASPO channels.  They in turn will get our requirement to
DCA who will eventually service us with (we are told informally) a
56KB connection.  I'm assuming that this connection will be a
conditioned circuit from the nearest node, probably over at AFWL on
the other side of Kirtland AFB.  I'm also aware that the DCA may elect
to install a node here in our facility.

I'm being quite free with terms that I don't fully understand.  For
instance, 'node'.  I'm assuming this is (with current technology and
given the state of the net) the same thing as a C-30.  Which runs some
node-control software (versions of which I understand are being
upgraded to allow older '1822' implementations to communicate with
newer 'x.25' { Basic | Standard } implementations...more terms I don't
fully understand).  I have policy guidance indicating in typical DoD
doublespeak that I Shalt Not Plan to use an 1822 interface, as if I
could figure out what I wanted.  

ACC glossies picked up at DEXPO indicate that the IF-11/HDH "operates
in HDH (1822-J) Packet Mode" and "the supported link level protocol
is HDLC/LAPB"....does that mean its on the verboten list for being
1822 or is it ok for me to buy?

As you can see, from what I can tell of the state of the net world, is
that things are in flux.  What I can't tell is whether the flux
affects the decisions I ought to make right now.  Due to the fact that
we are completely without the flavor of money that lets us make
capital expenditures when we need to, we rely TOTALLY on fallout funds
to make such purchases.  That is, our only budget is Operations and
Maintenance; upgrades depend on our being ready to use other peoples
unspent money during a very brief window in August and September.  If
I don't purchase interfaces next month, then DCA may show up with my
connection in May next year and we won't be able to buy the interfaces
then, and use the connection, until October!

I paint that bleak funding picture to explain WHY I need to answer the
interfaces question NOW.

Hm; actually, what I want is to use some smart box on the same
ethernet that services my VAXCluster.  This box needs to support up to
100 simultaneous users who have opened connections from TACs around
the country.  That '100' is usage projected within 3 years; initially,
I can probably get by supporting 50-60 simultaneous.  Once into the
Cluster, on any machine, a user should be able to use FTP and SMTP to
exchange with the rest of the internet, presumably transparently using
the same connection route...diagrammed here:

VAXCluster---(ethernet)----[Smart Box]===(56KB)===C30....

The reasons I want to do it this way is to avoid either 1) buying a
separate interface for every single node on the Cluster or 2) buying
one interface for one VAX and then burying that VAX serving i/o to the
rest of the cluster... is it a ridiculous concept?  Are these
ridiculous fears?

Given that 'what I want' probably doesn't exist; given that I fully
expect to have mangled at least one of these concepts and I HOPE you
can understand anyway; given that what I'm trying to do is comply with
directives to move all long-haul data communication requirements onto
the DDN, and my users are scattered from San Diego to West Palm Beach
to Boston to Seattle; I have several pleas to make.

Simple ones up front:
-anybody else already done this?  how?  are you using x.25 or 1822
 interfaces (or is that even a valid question?)
-anybody so inclined, straighten out whichever concepts I mangled;
-if I belong in another forum, please point; I've been looking for months.

More involved issues:

Other approaches:

We have 3 Ethernet Terminal Servers (each w/32 ports) on the ether
now.  They support dial-in modems and a few local hardwires.  Is there
a device which provides a sort of reverse TAC facility?  I believe it
may be a device I have heard called a PAD (for Packet Assembler/
Disassembler).  If I had numerous terminal ports coming in off the C30
via such a device I could connect each port to the Ethernet Terminal
Servers over which we have software configuration control.  This
solves my WORST problem of bringing my remote users in.  I could
probably then accomodate putting a single interface for FTP and SMTP
and outgoing TELNET onto one VAX in the Cluster.  Can anyone address
whether or not my understanding of a 'PAD' (or whatever its called) is
realistic?  Is this a reasonable model?

Here are three DEC part numbers for "commercial" (vice educational)
TCP/IP networking packages; I understand DEC offers these products
through a licensing arrangement with The Wollongong Group.

QAX74-CM   VAX IP/TCP VMS (supports DEUNA and DMR-11 interfaces)
QAXA9-CM   VAX IP/TCP DDN (supports DEUNA and ACC's IF-11/HDH)
QAXX1-C3   IP/TCP MicroVMS (supports DEQNA)

     (Just to save anyone the hassle of trying to find 
      the "educational" part numbers, here they are:
      QAX75-CM VAX IP/TCP VMS and QAXX2-C3 IP/TCP MicroVMS...)

Are these the best VMS products available?  Will any of them support
the [Smart Box] prayer I outlined above?  Could a MicroVAX II with the
QAXX1-C3 possibly be the Smart Box?  Could it support 50-100 users, or
would I need three (or 'n', tell me your guess at n) of them?  If I
HAD three of them, how many can be supported by a single C30?  If,
above, when I asked if my description of a [Smart Box] was a
ridiculous concept, you said to yourself, 'yes, ridiculous; he should
just use the blotzo' whats your blotzo?

I appreciate your patience.  I've been digging since February when
Bob Tinker from the David Taylor Naval Ship R&D Center asked about
ethernet-DDN gateways.  As of late April, he privately expressed
interest in new technology  under development, upon which a product
announcement was expected late this year.  I don't know if I can wait;
I hope you can tell from the tone of this that I have several degrees
of uncertainty about our approach.  We're ignorant and need help.  
From the real-(ignorant)-world of real requirements for day-to-day
long-haul data-communications, I'm sayin that we're mighty short on
solid information.  Comments on the above gratefully appreciated.

Lt Doug Olson, USAF
Air Force Contract Management Division
Future Information Systems Program Manager
-------
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Jul-86 10:51:25 EDT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        mod.protocols.tcp-ip
Subject:   Re: 127.0.0.1

but seismo is running 4.3bsd where it is supposedly fixed.

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Jul-86 13:55:15 EDT
From:      rbthomas@CAIP.RUTGERS.EDU (Rbthomas)
To:        mod.protocols.tcp-ip
Subject:   Re: TCP/IP for CDC?  Actually TCP/IP for Data-General

I would very much like to hear from any users of Data-General's TCP/IP
software that runs under AOS/VS on their MV/ series of computers.  We
are using it now (I am submitting this using it.)  but are having
serious stability problems.  I would like to hear of any other's
experiences.

Please reply by mail or voice phone.

Thanks in advance!

Rick Thomas

rbthomas@caip.rutgers.edu	ARPAnet
princeton!topaz!caip!rbthomas	UUCP
(210) 932-4301			Voice Phone

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1986 18:51:44 PDT
From:      POSTEL@B.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   re: reading list

One might start with a paper that appeared in the IEEE Communications
Magazine (March 85) and the IEEE INFOCOM '85 Conference.  The title is
"The DARPA Internet Protocol Suite", the author is B. Leiner.  Another
paper is "The DoD Internet Architecture Model" by Cerf and Cain in
Computer Networks of October 1983.

--jon.
-------
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Jul-86 16:13:22 EDT
From:      dolson@ADA20.ISI.EDU (Douglas M. Olson)
To:        mod.protocols.tcp-ip
Subject:   VAX IP/TCP

Preface:  This one got longer than I had expected.  I'd planned a
brief query to INFO-VAX for suggestions: but what this missive is
REALLY about is a newcomer to the DDN community trying to bring a new
installation aboard the net.  It is long.  I need some help.  If this
sort of thing isn't your bag, recommend you skip it!
---------
From the outside looking in, I'm having a hard time figuring out
what I'm supposed to obtain (hardware and software) to make my
VAXCluster able to communicate on the DDN using VAX-based
instantiations of TELNET, FTP, and (especially important) SMTP.  We
have just registered our connection requirement through the normal
MAJCOM and ASPO channels.  They in turn will get our requirement to
DCA who will eventually service us with (we are told informally) a
56KB connection.  I'm assuming that this connection will be a
conditioned circuit from the nearest node, probably over at AFWL on
the other side of Kirtland AFB.  I'm also aware that the DCA may elect
to install a node here in our facility.

I'm being quite free with terms that I don't fully understand.  For
instance, 'node'.  I'm assuming this is (with current technology and
given the state of the net) the same thing as a C-30.  Which runs some
node-control software (versions of which I understand are being
upgraded to allow older '1822' implementations to communicate with
newer 'x.25' { Basic | Standard } implementations...more terms I don't
fully understand).  I have policy guidance indicating in typical DoD
doublespeak that I Shalt Not Plan to use an 1822 interface, as if I
could figure out what I wanted.  

ACC glossies picked up at DEXPO indicate that the IF-11/HDH "operates
in HDH (1822-J) Packet Mode" and "the supported link level protocol
is HDLC/LAPB"....does that mean its on the verboten list for being
1822 or is it ok for me to buy?

As you can see, from what I can tell of the state of the net world, is
that things are in flux.  What I can't tell is whether the flux
affects the decisions I ought to make right now.  Due to the fact that
we are completely without the flavor of money that lets us make
capital expenditures when we need to, we rely TOTALLY on fallout funds
to make such purchases.  That is, our only budget is Operations and
Maintenance; upgrades depend on our being ready to use other peoples
unspent money during a very brief window in August and September.  If
I don't purchase interfaces next month, then DCA may show up with my
connection in May next year and we won't be able to buy the interfaces
then, and use the connection, until October!

I paint that bleak funding picture to explain WHY I need to answer the
interfaces question NOW.

Hm; actually, what I want is to use some smart box on the same
ethernet that services my VAXCluster.  This box needs to support up to
100 simultaneous users who have opened connections from TACs around
the country.  That '100' is usage projected within 3 years; initially,
I can probably get by supporting 50-60 simultaneous.  Once into the
Cluster, on any machine, a user should be able to use FTP and SMTP to
exchange with the rest of the internet, presumably transparently using
the same connection route...diagrammed here:

VAXCluster---(ethernet)----[Smart Box]===(56KB)===C30....

The reasons I want to do it this way is to avoid either 1) buying a
separate interface for every single node on the Cluster or 2) buying
one interface for one VAX and then burying that VAX serving i/o to the
rest of the cluster... is it a ridiculous concept?  Are these
ridiculous fears?

Given that 'what I want' probably doesn't exist; given that I fully
expect to have mangled at least one of these concepts and I HOPE you
can understand anyway; given that what I'm trying to do is comply with
directives to move all long-haul data communication requirements onto
the DDN, and my users are scattered from San Diego to West Palm Beach
to Boston to Seattle; I have several pleas to make.

Simple ones up front:
-anybody else already done this?  how?  are you using x.25 or 1822
 interfaces (or is that even a valid question?)
-anybody so inclined, straighten out whichever concepts I mangled;
-if I belong in another forum, please point; I've been looking for months.

More involved issues:

Other approaches:

We have 3 Ethernet Terminal Servers (each w/32 ports) on the ether
now.  They support dial-in modems and a few local hardwires.  Is there
a device which provides a sort of reverse TAC facility?  I believe it
may be a device I have heard called a PAD (for Packet Assembler/
Disassembler).  If I had numerous terminal ports coming in off the C30
via such a device I could connect each port to the Ethernet Terminal
Servers over which we have software configuration control.  This
solves my WORST problem of bringing my remote users in.  I could
probably then accomodate putting a single interface for FTP and SMTP
and outgoing TELNET onto one VAX in the Cluster.  Can anyone address
whether or not my understanding of a 'PAD' (or whatever its called) is
realistic?  Is this a reasonable model?

Here are three DEC part numbers for "commercial" (vice educational)
TCP/IP networking packages; I understand DEC offers these products
through a licensing arrangement with The Wollongong Group.

QAX74-CM   VAX IP/TCP VMS (supports DEUNA and DMR-11 interfaces)
QAXA9-CM   VAX IP/TCP DDN (supports DEUNA and ACC's IF-11/HDH)
QAXX1-C3   IP/TCP MicroVMS (supports DEQNA)

     (Just to save anyone the hassle of trying to find 
      the "educational" part numbers, here they are:
      QAX75-CM VAX IP/TCP VMS and QAXX2-C3 IP/TCP MicroVMS...)

Are these the best VMS products available?  Will any of them support
the [Smart Box] prayer I outlined above?  Could a MicroVAX II with the
QAXX1-C3 possibly be the Smart Box?  Could it support 50-100 users, or
would I need three (or 'n', tell me your guess at n) of them?  If I
HAD three of them, how many can be supported by a single C30?  If,
above, when I asked if my description of a [Smart Box] was a
ridiculous concept, you said to yourself, 'yes, ridiculous; he should
just use the blotzo' whats your blotzo?

I appreciate your patience.  I've been digging since February when
Bob Tinker from the David Taylor Naval Ship R&D Center asked about
ethernet-DDN gateways.  As of late April, he privately expressed
interest in new technology  under development, upon which a product
announcement was expected late this year.  I don't know if I can wait;
I hope you can tell from the tone of this that I have several degrees
of uncertainty about our approach.  We're ignorant and need help.  
From the real-(ignorant)-world of real requirements for day-to-day
long-haul data-communications, I'm sayin that we're mighty short on
solid information.  Comments on the above gratefully appreciated.

Lt Doug Olson, USAF
Air Force Contract Management Division
Future Information Systems Program Manager
-------

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Jul-86 20:29:52 EDT
From:      mills@DCN6.ARPA
To:        mod.protocols.tcp-ip
Subject:   The multi-home problem again

Folks,

I wondered why it took so long to resolve ISI.EDU names and discovered the
following, which I'm sure you will enjoy. A request to resolve A.ISI.EDU sent
to [10.0.0.51] (SRI-NIC.ARPA) returns [10.2.0.27], [10.1.33.27], [128.9.0.33],
[10.1.0.52] and [128.9.0.32]. The fuzzball namesolver starts cranking on this
list and the following nonsense comes back:

16:04:13 Server	[10.2.0.27]	[responded from address 128.9.0.33]
16:04:18 Server	[10.2.0.27]	[responded from address 128.9.0.33]
16:04:23 Server	[10.2.0.27]	[responded from address 128.9.0.33]
16:04:29 Server	[10.1.33.27]	[no response]
16:04:34 Server	[10.1.33.27]	[no response]
16:04:39 Server	[10.1.33.27]	[no response]
16:04:40 Server	[128.9.0.33]	[responded with requested data [26.3.0.103]

Yes, I really mean that the requests to [10.2.0.27] came back, apparently with
valid data, but the address in the IP source-address field was [128.9.0.33],
which certainly violates the Principle of Least Astonishment. It turns out all
three of these addresses belong to VAXA.ISI.EDU, but on different networks, so
that host is clearly fuddled.

The last buzzard to catch this bug was SRI-NIC.ARPA. Apparently, it bites
VAXen too. Hans-Werner Braun reports seeing responses from some servers coming
back with [127.0.0.1] in the IP source-address field. That bit of cosmic
goofiness would certainly amuse our Martian friends.

Dave
-------

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      18-Jul-86 17:34:12-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   The multi-home problem again
Folks,

I wondered why it took so long to resolve ISI.EDU names and discovered the
following, which I'm sure you will enjoy. A request to resolve A.ISI.EDU sent
to [10.0.0.51] (SRI-NIC.ARPA) returns [10.2.0.27], [10.1.33.27], [128.9.0.33],
[10.1.0.52] and [128.9.0.32]. The fuzzball namesolver starts cranking on this
list and the following nonsense comes back:

16:04:13 Server	[10.2.0.27]	[responded from address 128.9.0.33]
16:04:18 Server	[10.2.0.27]	[responded from address 128.9.0.33]
16:04:23 Server	[10.2.0.27]	[responded from address 128.9.0.33]
16:04:29 Server	[10.1.33.27]	[no response]
16:04:34 Server	[10.1.33.27]	[no response]
16:04:39 Server	[10.1.33.27]	[no response]
16:04:40 Server	[128.9.0.33]	[responded with requested data [26.3.0.103]

Yes, I really mean that the requests to [10.2.0.27] came back, apparently with
valid data, but the address in the IP source-address field was [128.9.0.33],
which certainly violates the Principle of Least Astonishment. It turns out all
three of these addresses belong to VAXA.ISI.EDU, but on different networks, so
that host is clearly fuddled.

The last buzzard to catch this bug was SRI-NIC.ARPA. Apparently, it bites
VAXen too. Hans-Werner Braun reports seeing responses from some servers coming
back with [127.0.0.1] in the IP source-address field. That bit of cosmic
goofiness would certainly amuse our Martian friends.

Dave
-------
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Jul-86 21:51:44 EDT
From:      POSTEL@B.ISI.EDU
To:        mod.protocols.tcp-ip
Subject:   re: reading list


One might start with a paper that appeared in the IEEE Communications
Magazine (March 85) and the IEEE INFOCOM '85 Conference.  The title is
"The DARPA Internet Protocol Suite", the author is B. Leiner.  Another
paper is "The DoD Internet Architecture Model" by Cerf and Cain in
Computer Networks of October 1983.

--jon.
-------

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19-Jul-86 00:00:27 EDT
From:      JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: Lisp machines don't receive network level broadcasts right, causing net mayhem


	(For those who are lost, this is about the incident I reported
where broadcast RIP packets from a subnet gateway were being reforwarded
by all of a certain class of machine which didn't recognize them as
broadcast, causing a massive jamup on the net.)
	I sent a message out to TCP-IP a few months (28 April if you want
to look it up in the archives) ago in which I discussed a similar topic
at length. (The question there was when to send ICMP Error packets).
The general philosophy behind the answer here is the same. Had the
algorithm about 'hosts not doing anything with wrong packets that were
broadcast' been followed by the hosts here, the problem would not have
occurred.

	If a host receives what looks to it like a misdirected packet,
it got it either because a gateway was confused or some host was. In
the first case, things are really in trouble anyway; reforwarding it
could just cause a loop or other serious problems. In the second, I
don't think that you should encourage broken behaviour on the part of
hosts; if they didn't send the packet to the right place they should
be fixed.
	The real problem is that in practice usually when a host sees
a packet it doesn't recognize it's not because the packet was sent to
the wrong place, but because there is some strange address in there
the host didn't recognize. In this case it was a subnet broadcast
address, and a host that didn't recognize that it was on a subnetted
net. In the future it might be multicast addresses, or whatever.
In either case, doing anything except ignoring it is the wrong thing.
Yes, maybe in .001% of the cases, forwarding the packet on is the
right thing, but in the rest it's the wrong (and usually disastrous)
thing to do. Clearly, the cost/benefit analysis says that forwarding
the packet is the wrong thing.

	Noel
-------

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19-Jul-86 12:15:45 EDT
From:      ron@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   RING vs. ETHER - Theory and practice.


      Dave Clark once again observes that a token ringnet outperforms an
      Ethernet in handling back-to-back packets.  The ringnet has an
      automatic retransmission function built into the network
      interface, and will retransmit rejected packets until they get
      accepted, while an Ethernet interface loses subsequent packets if
      they follow the first one too closely.

In theory, but let us look at two fielded devices.  The INTERLAN N1010A
Ethernet interface and the PROTEON 10MB RINGNET.  The INTERLAN  handles
multiple incoming packets by buffering some number of messages comming
in from the net in interface memory while waiting for the host to begin
the data transfer.  The PROTEON can not accept back to back messages
because the board does not reset to copying messages from the interface
after the end of the first message so it misses the header of the second
message.  There is no automatic retransmit because the source board drains
the ring until it sees its own message come back, which should be at the
beginning of the train of messages.  It can't leave it in the ring, because
it will be eaten by another interface who had transmitted a message.  It
can't retransmit until the token comes by.  I've tried reenabling copy
as soon as the DMA has finished, but there is still a delay, and I also
feel that something is amis in the interrupt logic when I do this.

You are still at a slight win because it is possible for the lower levels
to tell when retransmission is needed, however, a lot of retransmission
is needed because of the misdesign of the interface, significantly more
so than is ever needed on our Ethernets.

Not to say that I am down on the Proteons, much of what we are doing at
BRL would be difficult or impossible without them.  I just wish they
could double buffer so that you would not miss the header of successive
packets.

-Ron

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19-Jul-86 23:12:26 EDT
From:      dave@RSCH.WISC.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: The multi-home problem again

Dave Mills writes:
>Yes, I really mean that the requests to [10.2.0.27] came back, apparently with
>valid data, but the address in the IP source-address field was [128.9.0.33],

This appears to be a bug in the 4.2 and 4.3 UDP implementations.
Actually, the way that the network interface between user programs and
the kernel is defined, there isn't any way to fix this in all cases.
This is because a user program can't specify which of the addresses for
a host should be used as the source address.

I ran across this bug yesterday while making queries to the UDP time
service on one of our hosts.  The same sort of thing happened, the
source address was not the address to which I had sent the query but
the other address for that host.

My solution to this problem is to recognize all of the addresses for a
host.  This seems easier than adding yet another version of the "send"
system call to 4.3.  I don't think this will help in the case of a name
server, though.  You can't possibly recognize an address you don't
know about!

dave

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20-Jul-86 03:00:57 EDT
From:      sjl@amdahl.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Ways to input your X.400/MOTIS concerns

In message <8607150327.AA07564@opus> nbires!atkins@ucbvax (Brian Atkins)
states that the Corporation for Open Systems (COS) is a good way to input
to the international standards bodies and mentioned the National Bureau of
Standards sponsored OSI Implementors Workshop as a less expensive alternative.

I appreciate him mentioning the OSI Implementors' Workshops because they have
been very important in moving OSI protocols from paper to practice.  However,
it is important to understand that the main way of affecting standards
development is through the national standards committees.  The main role of
the OSI Implementors' Workshops is to interpret existing standards, although
they will sometimes send liaison statements to standards groups.  The role
of COS is not to represent COS members in standards bodies - members are
expected to send their own representatives.  COS is intended to accelerate
the use and development of OSI and ISDN standards by developing commonly agreed
tests and providing a forum in which members are made aware of areas where
standards development needs to be accelerated.

When discussing COS and the OSI Implementors' Workshops it is useful to know
that they have a complementary relationship.  COS intends to base the protocol
inplementation tests on the agreements reached in the Workshops.  COS has
also sent the Workshops requests regarding the scheduling and priority of
the subjects discussed in the Workshops.  A significant number of COS members
send representatives to the Workshops.

I both attend the OSI Implementors' Workshops and participate in COS activities.
As editor of a report produced by the pre-COS group (which led to COS being
formed) and as chair of the COS Architecture Committee I have consistently
recommended using the agreements reached at the Workshops.  However, I do not
believe that COS and the OSI Implementors' Workshops currently represent
alternatives - they are doing different things.  Neither is primarily a
method for input to the international standards bodies; this purpose is served
by ANSI approved committees or their equivalents in other countries.

Stephen J. Langdon                  ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl

[ The article above is not an official statement from any organization
  in the known universe. ]

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20-Jul-86 11:23:46 EDT
From:      ron@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  The multi-home problem again

It is not necessary to add a new version of the send call, I believe
sendmsg allows you to specify an arbitrary source address, but it is
a little harder to deal with.

-Ron

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20-Jul-86 11:33:24 EDT
From:      JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: RING vs. ETHER - Theory and practice.


	First, let me correct some misstatements in both your characterization
of the ring systems (one of which I had a hand in designing at MIT). It does
not automatically retransmit packets; perhaps the person was confusing it with
Ethernet interfaces which do retransmit packets automatically in case of a
collision. Also, the 80MB ring interface does have on board packet buffer and
it will receive back to back packets without host intervention, although the
10MB ring interface does not.

	What both 10M and 80M *do* have (as you alluded to) is a low level
*acknowledgment*. I.e., you know (with some reasonable degree of probability)
whether or not the intended recipient got the packet. The reason I think that
this is important is because it is starting to become clear that dropping
packets is a Bad Thing in terms of the effect on performance. Any losses and
retransmissions have serious effects on the performance of 'single-ACK'
protocols like TCP, especially when you are running at high data rates. The
single ACK is such a weak mechanism that it should only be used as a backstop
for rare failures; if you have to use it a lot, you lose a lot of performance.
Since we are stuck with TCP -> you should not drop packets.
	The point of all this is that nets ought to have a reasonable
hardware acknowledgement feature that would let you know when a host could
not accept a packet destined to it. I don't know why the didn't put one in
Ethernet; it would have been really trivial. The CHAOS hardware built at
the MIT AI Lab (which was a 4MB/sec Ether like system) had such a feature;
the recipient jammed the cable (causing a collision) if a packet for that
destination could not be handled.
	What amazes me is that although the IEEE Ethernet spec did make all
sorts of changes to the spec, of little or no pactical utility as far as I can
see (e.g. Ethernet demonstrably works fine without a length field), they
didn't fix this glaring defect! A typical standards committee: they make all
sorts of gratuitous changes to an existing widespread spec, resulting in a
massive incompatability problem, without fixing any real problems.

	I guess it is true that with a multi-buffered interface you are less
likely to drop packets, but it still does help. Also, low level acks can help
gateways a lot. If the next hop gateway on a route dies, you can detect it,
and reroute around it. You can also give more informative error messages. (How
I hate 'connection timed out' - I want to know why! The annoying thing is that
even when gateways go to great lengths to send back ICMP error messages, most
hosts do not reflect them to users. When I put ICMP error support into a
gateway, I could not find a host at MIT that would take the messages and use
them to make an intelligent error message for the user!)

	Noel
-------

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20-Jul-86 16:19:03 EDT
From:      Lixia@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: RING vs. ETHER - Theory and practice.

I wrote the original paragraph of 

      Dave Clark once again observes that a token ringnet outperforms an
      Ethernet in handling back-to-back packets.  The ringnet has an
      automatic retransmission function built into the network
      interface, and will retransmit rejected packets until they get
      accepted, while an Ethernet interface loses subsequent packets if
      they follow the first one too closely.

So I'd better clean up my own mistake.  As Noel has pointed out, the
ringnet interface returns an acknowledgment; therefore when the receiving
interface cannot catch up with incoming packets, the source host network
driver quickly retransmits any negatively acknowledged packet till the
interface returns an positive-ACK (or till hits some max retrans number).
For Ethernet, if the receiving interface doesn't get a packet right, the
packet is lost.

Having buffers at the interface is helpful, for both ethernet and ring.
Ethernet is a loser in that, using Noel's word, it lacks a low-level ACK.

Lixia
-------

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20-Jul-86 23:30:00 EDT
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: RING vs. ETHER - Theory and practice.

Noel,

Please elaborate on "single ACK" problem. As you know, TCP ACKS are at least
"inclusive" so that subsequent ACK can make up for one lost, if more data
is sent and received. This isn't perfect, of course, since "inclusive" ACK 
doesn't help if data was lost at the receiver. Perhaps you are thinking about
ACKs which cover data received past data lost (selective ACKS)? We looked at
this several times but the complexity of the mechanism did not seem to
buy enough to justify it.

Vint

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1986 23:30-EDT
From:      CERF@A.ISI.EDU
To:        JNC@XX.LCS.MIT.EDU
Cc:        ron@BRL.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: RING vs. ETHER - Theory and practice.
Noel,

Please elaborate on "single ACK" problem. As you know, TCP ACKS are at least
"inclusive" so that subsequent ACK can make up for one lost, if more data
is sent and received. This isn't perfect, of course, since "inclusive" ACK 
doesn't help if data was lost at the receiver. Perhaps you are thinking about
ACKs which cover data received past data lost (selective ACKS)? We looked at
this several times but the complexity of the mechanism did not seem to
buy enough to justify it.

Vint
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Jul-86 01:11:44 EDT
From:      mark@cbosgd.ATT.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: RING vs. ETHER - Theory and practice.

In article <12224206784.24.JNC@XX.LCS.MIT.EDU> you write:
>	The point of all this is that nets ought to have a reasonable
>hardware acknowledgement feature that would let you know when a host could
>not accept a packet destined to it. I don't know why the didn't put one in
>Ethernet; it would have been really trivial. The CHAOS hardware built at
>the MIT AI Lab (which was a 4MB/sec Ether like system) had such a feature;
>the recipient jammed the cable (causing a collision) if a packet for that
>destination could not be handled.

I note that 802.2 has a whole bunch of "connection oriented" features
added onto the side of Ethernet.  While I assume most of us are ignoring
them (I gather they were put there by X.25 types) I wonder if there would
be a clean way to use these facilities to get an ack or nak back for
normal IP type datagrams?  Since I gather we have some standards to
work out regarding ARP on 802.2 anyway, maybe this would be a good
time to adopt some other conventions too?

	Mark

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Jul-86 02:14:28 EDT
From:      karels@MONET.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: The multi-home problem again

The previous answer to Dave Mills' observation on the nameserver
for A.ISI.EDU requires considerable clarification and correction.
Actually, I was going to deny any responsibility on behalf of 4.2
and 4.3BSD UNIX for dealings between a fuzzball and TOPS-20, but a quick
check shows that the server for ISI now runs on a 4.2BSD VAX.
I guess I'm not off the hook so easily.

The previous reply was totally incorrect in its claims about 4.3.
However, 4.2 has a serious problem when it comes to the Principle
of Least Astonishment when it comes to UDP return addresses.
First, a process receiving UDP datagrams (including a server)
receives the datagram "from" address, but not the "to" address.
Thus, a server can take no action to ensure that the source address
of its reply is the same as the destination address of the request
on a multihomed host.  (The preceeding is still true in 4.3.)  Both 4.2
and 4.3 attempt to choose UDP source addresses according to the destination
address, but 4.2 makes a somewhat feeble attempt.  It uses its address
on a network shared with the destination, if any (which is generally correct),
but uses its "primary" address for all other destinations.  The "primary"
address is the address for the first network interface in the system
configuration file.  VAXA.ISI.EDU could apparently be helped considerably
by placing its imp interface first in its kernel configuration table.

4.3 makes a better attempt at choosing source addresses for datagrams
(and client-initiated TCP connections).  It uses its address on the network
through which it routes the packet.  However, for the name-domain system,
this is not sufficient that name solvers may depend on the server's
choice of source address.  In particular, if the server is known by multiple
addresses, the name solver may or may not use the "closest" address for the
server (the address on the network by which the request will arrive).
It seems to be reasonably simple to recognize a reply to one's query,
however, without depending on the source address of the reply.  That is
fortunate, as the predominant servers run on hosts that may not use
the expected source address for all replies.

The comments made by Dave Cohrs about the "UDP bug" concerning inability
to specify the source address of a datagram were incorrect.  It is possible
for the source address to be bound (using the bind system call) before
sending the datagram.  It would be reasonable for a knowledgeable server
to set up one descriptor for each source address in this way.  It is actually
the system interface for reception of datagrams that is limiting.

By the way, the Martian-grams which Dave Mills mentioned (replies from
127.0.0.1) are more difficult to explain.  The last wave of attacks
were ICMP error messages with that source address that came from
a beta 4.3 host.  The code to select the ICMP source address was
unfinished at the time of the beta release, although I had forgotten
that by the time of the attack.  The test release thus used the "primary"
address, which in 4.3 is the first address set.  At one site, the primary
address was thus the one used for the loopback, a configuration error
that I had not imagined.  The error would be much less serious with
the released version of 4.3.  Seismo appears to still be running
the beta test version or a mixture of the two.  With either version,
the loopback address can be set to any value.  To encourage use of
officially-assigned addresses, the release contains an unusable
definition of the loopback address that must be changed.

		Mike

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Mon 21 Jul 86 09:51:55-PDT
From:      "Robert J. Scott" <scott@nrl-lcp>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   please remove
Dear List Maintaniner.
	We would like to be removed from the tcp-ip distribution list as we are
being overwhelmed with messages that we can't give sufficient time.

thank you,
NRL-LCP
------
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Jul-86 09:13:16 EDT
From:      jas@BRUBECK.PROTEON.COM
To:        mod.protocols.tcp-ip
Subject:   Re: Re: RING vs. ETHER - Theory and practice.

I'll answer two open questions at once here.

The 802.2 connection oriented features probably really exist so that IBM
could run SNA on "their" 802.5 Token-Ring Network. SNA absolutely
requires a reliable data-link layer, this is essentially the only level
where there are any data integrity features in the SNA architecture.
That's why IBM's Token-Ring board has a complete 802.2 connection
oriented (VC) in the firmware of their PC board, along with an extended
XID frame for SNA.

I don't think that using a VC data link for IP is going to help you on a
LAN. First of all, nobody's going to manage to write a 6-10 megabit/sec
802.2 VC layer. Secondly, stacking VC layers does not always work well.
Third, this is not really the way TCP/IP was intended to be used. (Of
course, on slow nets like the ARPANET, the VC code does not get in the
way.) Fourth, the sequence numbering is only modulo-128. This can get
consumed rapidly by tinygrams, and you will go into senquence number
wait.

On the issues of single ACK in TCP, this has to do with degenerative
congestion when packets are being dropped. The sender sends 5120 bytes
in ten TCP packets. The second one gets dropped due to congestion. The
ACK of the first comes back. The last 8 packets get retransmitted. The
second one (orignal fourth) gets dropped due to congestion. Repeat. What
we have is a tendency towards instability when packets start getting
lost. Note that the congestion is getting worse for eveyone due to this,
since packets are being sent many extra times. This sort of problem is
why people are developing protocols with what I call "ACK vectors", such
as NETBLT at MIT, and NETEX from Network Systems. These provide the fate
of the last 'n' packets in ACKs, rather than a ACK-point. Only the
dropped packet gets retransmitted in these protocols.

					john shriver
 					proteon
-------

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Jul-86 09:16:00 EDT
From:      SST.D-BIGELOW%KLA.WESLYN%Wesleyan.BITNET@WISCVM.WISC.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Tektronix TCP/IP news?


     Bob, a TEKTCP mailing list has indeed been created.  The address
is TEKTCP%KLA.Weslyn@Wesleyan.Bitnet, and requests go to
TEKTCP-Request%KLA.Weslyn@Wesleyan.Bitnet.  I'll go ahead and add you
to the list.  It just started a week or so ago, with less than two
dozen people.  If it grows much I'll ask for redistribution points for
nets other than Bitnet, but for now it's a low-volume, non-moderated
rebroadcast list.  Topics are anything having to do with using the
Tektronix TCP/IP package on VAX/VMS.

     Regarding your specific questions about Tek TCP, I'll send you
more information in a separate message without CCs.

                                   -- Doug

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Jul-86 13:12:54 EDT
From:      leong@ANDREW.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   Re: RING vs. ETHER - Theory and practice.


In IEEE802.5 (a.k. IBM token ring), there is two low level acknowlegemnt of
sort in the MAC layer encapsulation - at the end of the frame. When a station
grap a token for transmission, it will set the A and C bits (Address Recognised
and Frame Copied) to 0. As the frame zap round the ring, if all goes well, the
detsination station will receive the frame and set both the A and C bits to
1. When the frame continues its merry way back to the sender for purging, the
sender can deduce from the status of the A and C bit what has happened. 

If A and C are both set to 1, all's well.
If A and C are 0,  there is a good probability that the destination is not up
or on the net.
If A is 1 and C is 0 then the receiving station has a congestion problem.
If A is 0 and C is 1, we have something really strange going on.

Note that the acknowlegement is all done within one ring rotation as the A and
C bit is flipped on the fly by the receiver and is very efficient. There is
no explicit ACK frame involved.

Furthermore, the IBM token ring has a nifty feature built into the chip set.
If an interface detects a congestion situation, it will send out a special frame
(MAC frame) to tell whoever wants to know (network monitoring station) that
a soft error situation has been detected. It is really useful for network management
and planning.

Leong

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Jul-86 14:44:56 EDT
From:      leong@ANDREW.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   Re: RING vs. ETHER - Theory and practice



Mark,

Re : 802.2 Type 2 operation

802.2 offers you Type 1 or Type 2 operation. Type 1 is pure datagram stuff with
the ARPANET's "take your chance" approach while Type 2 goes the other extreme
and do both flow control and error recovery. 

The general idea is that if you are going for a heavy weight Tranpsort Layer
already such as TCP or TP-4, you should leave every thing to that layer and
chose Type 1. If you are going to use light weight Tranpsort layer such as TP-0,
then Type 2 is for you. (Interestingly, IBM is using Type 2 since under SNA,
the link layer is the only level that will do error recovery). 

Hence unless we can get IEEE802.2 to create a Type 1.5, we don't think it is
worth our while to spend the cycles required for Type 2. (Actually, having a
Type 1.5 that will do low level acknowlegement but without flow control and
error recovery procedure may be quite useful - particularly for network level
gateway machines).

Leong

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Jul-86 15:27:53 EDT
From:      karn@MOUTON.BELLCORE.COM (Phil R. Karn)
To:        mod.protocols.tcp-ip
Subject:   TCP retransmission efficiency

A virtual circuit link layer on Ethernet? Surely you jest!  I guess Ethernet
was too simple, cheap, fast and reliable to be left alone by IBM.  Must be
the second law of thermodynamics in action...

I'm not sure John Shriver's scenario with TCP is up to date.  More modern
implementations ("modern" defined as "implementing John Nagle's
recommendations in RFC 896") seldom suffer from this problem.  First of all,
in the majority of situations the Nagle Rule allows only one segment to be
in flight at a time. Obviously a lot of problems go away if you can operate
in "stop and wait" mode.

Only when the bandwidth requirement on the connection exceeds one Maximum
Segment Size per round trip interval will there be more than one segment in
flight at one time.  (This assumes that the receive window is greater than
the MSS, of course.)  Even so, if an early segment gets lost, the receiving
TCP is supposed to place the later segments on its resequencing queue and
quietly await retransmission of the missing segment. When the sender times
out, it is supposed to resend ONLY the oldest unacknowledged segment. This
fills in the hole, and the receiver will now acknowledge all the segments
that it has received. The transfer now continues without any unnecessary
retransmissions.

So as long as the receiver uses "in-window" acceptance (i.e., implements
resequencing) and the sender uses "first-only" retransmission, it's pretty
easy to see that only those segments actually lost are retransmitted.  And
this is done without any incompatible changes to the protocol.

Of course, this assumes that ACKs aren't lost very frequently. If they are,
then it makes sense to consider ACKing ACKs. I.e., ACKs are retransmitted by
the receiver until it gets either a new data packet from the transmitter or
an indication that there is no more data to send. This looks like a good
idea on very lossy networks (e.g., packet radio -- this idea was first
proposed by the Alohanet folks) and I've proposed it for use as an
experimental amateur packet radio link level protocol. At the transport
layer, however, you had better have reasonably low loss rates or the more
costly end-to-end retransmissions (even ACK retransmissions) would eat you
alive.

Phil

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Jul-86 15:46:21 EDT
From:      scott@nrl-lcp ("Robert J. Scott")
To:        mod.protocols.tcp-ip
Subject:   please remove

Dear List Maintaniner.
	We would like to be removed from the tcp-ip distribution list as we are
being overwhelmed with messages that we can't give sufficient time.

thank you,
NRL-LCP
------

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Jul-86 17:58:20 EDT
From:      dave@RSCH.WISC.EDU (Dave Cohrs)
To:        mod.protocols.tcp-ip
Subject:   Re: The multi-home problem again

Sorry about the mis-info.  I didn't realize that 4.3 was that different
from 4.3alpha and 4.3beta.

Thanks for the clarification.

dave

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jul 86 21:14 EST
From:      <GNAGARAJ%SUNRISE.BITNET@WISCVM.ARPA> (Gopal Nagarajan |, 423-3003 |)
To:        tcp-ip@sri-nic.arpa
Subject:   

        Please delete me from your mailing list. Thank you.

                                                G Nagarajan
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Jul-86 22:14:00 EDT
From:      GNAGARAJ@SUNRISE.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)


        Please delete me from your mailing list. Thank you.

                                                G Nagarajan

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 86 08:59:00 PST
From:      <gary@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   Confused in VAX/DDN Land
Doug,

Please give me a call here at ACC.  I will attempt to set the record
straight on our products as well as give you some guidance as to how
you may want to approach your application...don't feel like the 
Lone Ranger...many others such as yourself are asking the same questions..
Tonto is not far behind...

Gary
------
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22-Jul-86 12:59:00 EDT
From:      gary@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   Confused in VAX/DDN Land

Doug,

Please give me a call here at ACC.  I will attempt to set the record
straight on our products as well as give you some guidance as to how
you may want to approach your application...don't feel like the 
Lone Ranger...many others such as yourself are asking the same questions..
Tonto is not far behind...

Gary
------

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22-Jul-86 20:47:53 EDT
From:      mills@DCN6.ARPA
To:        mod.protocols.tcp-ip
Subject:   Undocumented service ports

Folks,

Our spacewatch network reports sighting TCP connections to port 104, which
is not an assigned number according to RFC-960. This number, however, is
in the range usually associated with a standard network service and is
assigned only after public disclosure and documentation. I suspect from
context this number has been assigned our X.400 crew, which leads me to
politely inquire if encapsulation information is available so we can all
claim our First-Crash Awards.

Dave
-------

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      22-Jul-86 22:27:09-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Undocumented service ports
Folks,

Our spacewatch network reports sighting TCP connections to port 104, which
is not an assigned number according to RFC-960. This number, however, is
in the range usually associated with a standard network service and is
assigned only after public disclosure and documentation. I suspect from
context this number has been assigned our X.400 crew, which leads me to
politely inquire if encapsulation information is available so we can all
claim our First-Crash Awards.

Dave
-------
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Jul-86 09:34:14 EDT
From:      jas@BRUBECK.PROTEON.COM
To:        mod.protocols.tcp-ip
Subject:   Re: Re: RING vs. ETHER - Theory and practice

There is a proposed type 3 802.2 under consideration, which is reliable
datagram. Still, the A and C bits help so much that I'm not so sure
this will be valuable for TCP/IP.
					john shriver
					proteon
-------

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Jul-86 11:58:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   Computer Implementations Sociologists

I'm wondering if there are any social scientists that study why various
aspects of computers exist the way they do.  My current questions relate
to languages and network protocols.  Other topics include computer
architectures, operating systems and I'm sure several others.

Languages is an older field.  I'm not really interested in a simple
history of FORTRAN or BASIC or COBOL or ADA or CommonLisp.  I'm more
interested in the overall motivations, goals and constraints placed upon
the designers, how well the result met the goals, what problems the
language didn't solve, how the goals were found to be faulty, how the
goals change over time (e.g., as memory and disk gets cheaper), etc.
This goes all the way from conception, implementation, revision,
widespread usage, evolution, etc.

Networks are a newer field, but certainly has had its share of good and
bad ideas.  Again, I'm not interested in a simply history of the
ARPAnet, LANs, etc.  I'm interested in such things as the constraints
under which designers use numeric encoding instead of symbolic values.
Is it host language support?  Is it to reduce byte count for 1970 packet
charges that haven't evaporated in this the information age?  Is it just
historical inertia?  Has anybody studied the "Not made here" syndrome?
What is the cause of it?  Is it simple arrogance, or do original
designers plan things too specifically that can be generalized?  If so,
do they realize what they are doing, or does one learn to be more
general as one gets older and wiser?  How do protocols become imposed on
people?  What is the effect of the imposition?

Has anybody studied possible hypocrisy among designers?  For example, if
a standard is to be imposed, what if it is known to be unsuitable for
some organization?  How many things are done because of underying, and
possibly not realized, job security desires?

Those are the types of questions/debates I'm interested in seeing
outsider study results.  I'm sure we all have opinions on some of the
above.  I do.  Doing some soul searching to learn why one has opinions
can sometimes be very enlightening.  Any leads on professionals or
publications that address these?

Replies to me only, please.  I'll redistribute replies to interested
individuals.  I'd be interested in actively discussing this, but I don't
have time in the short term.

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Jul-86 14:09:07 EDT
From:      minshall%ucbopal@UCBVAX.BERKELEY.EDU (Greg Minshall)
To:        mod.protocols.tcp-ip
Subject:   tn3270 fixes (thanks!)

Bob and Alan,
	I would like to thank you all a lot.  Your collectively inspired
mods to tn3270 will save me a fair amount of work.  I will incorporate these
changes as soon as I am back on campus regularly - so it may be another
month or so.

Greg

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27-Jul-86 22:59:17 EDT
From:      karels@MONET.BERKELEY.EDU (Mike Karels)
To:        mod.protocols.tcp-ip
Subject:   Re: TCP retransmission efficiency

Phil:

I'm not sure you're up to date on TCP either.  The Nagle algorithm allows
only one *small* packet in flight (one of less than the maximum
segment size).  Essentially all applications other than telnet/remote
terminal use more than one segment per round-trip interval.  Very few
applications are satisfied with "stop and wait" mode, nor do they refrain
from sending additional data once a maximum segment sized packet has been
sent.

I don't want to think about ACKing ACKs; new data segments are sufficient
acknowledgement, and retransmitted data segments are good enough NAKs.

		Mike

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Jul-86 00:03:39 EDT
From:      karn@KA9Q.BELLCORE.COM (Phil Karn)
To:        mod.protocols.tcp-ip
Subject:   Re: TCP retransmission efficiency

Forget the Nagle algorithm for the moment; I confused the issue by
bringing it up.

Assuming ACKs aren't lost, unnecessary retransmissions are avoided
as long as you have "first only" retransmission at the sender plus
"in window" acceptance at the receiver.

As I said, "ack retransmission" (i.e., acking acks) is a last-ditch
approach for use over very unreliable links. I'm not sure it'd be
at all appropriate at the transport (host-host) layer.

Phil

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Jul-86 12:39:11 EDT
From:      geof@imagen.UUCP (Geof Cooper)
To:        mod.protocols.tcp-ip
Subject:   Throughput to IMAGEN TCP-IP Printers running V2.1 & V2.2

There is a bug that affects throughput in IMAGEN's V2.1 and V2.2
TCP software.  For people who are familiar with TCP-IP, the bug is
explained below.  The bug limits throughput to 32 Kbits/s when the
sending TCP's buffer space is less than 6144 bytes.  This is the case,
by default, for BSD 4.2 UNIX systems (including SUN's).  The bug
is fixed in IMAGEN's release V3.3 software, which is now in beta
test.

32 Kbits/s is sufficient throughput for most documents, since the printer
processes most data no faster than this.  Bitmap data is the exception
(especially when using language bitarray but also when using IMPRESS),
since the image processor would process this data faster if it were
received faster.  TCP sites may improve throughput for bitmap data by
increasing the amount of "send" buffer space to be >= 6144 bytes.

UNIX sites can accomplish this without resort to sources, by patching
the UNIX kernel to set the variable "tcp_sendspace" to be 6144:
        # adb -w /vmunix /dev/kmem
        tcp_sendspace/W 0x1800
        tcp_sendspace:  0x800      =   0x1800
        $q
        #
This patches the in-memory copy of UNIX (the one that is running now).
The same patch, with a question mark instead of a slash (tcp_sendspace?W)
will alter the bootable binary, causing the patch to be automatically
installed every time the system is rebooted.

The effect of the patch is to increase the buffer space reserved
for outgoing data for every TCP connection to be 6144 bytes.  It
is not possible to change this parameter for specific connections,
so the global limit must be changed.  The impact on the system is to
reserve 4KB more memory per connection, so the memory requirements
of the UNIX kernel will rise slightly.  [Somewhat improved throughput
between UNIX systems can be achieved by also setting the kernel
variable tcp_recvspace to be 6144 for both cooperating systems. I
have not measured the speed improvement in this case].


Explanation of bug:
==================

The IMAGEN TCP software is an "upcall" implementation, such that there are
no per-connection packet queues.  Each packet is individually and
fully processed as it is received.  When a packet containing data is
received, the software sets a flag to generate an ACK.  If the packet
consumes more than a particular percentage of the offered window,
the ACK is sent immediately.  Otherwise, there might be another packet
waiting to be processed at the network interface, so the ACK is withheld
to allow additional packets to share the same ACK.  A timer is set for a
short delay (1/2 a second), after which the ACK is sent anyway.

The bug occurs when the amount of buffer space for that the sending
TCP has reserved for outgoing data, say N bytes, is much less than
the offered window, say M bytes.  In this case the "short delay" lasts
its full duration after each burst of N bytes.  The throughput of the
connection is thus very close to N/.5 or 2N bytes per second, since
the time to actually transmit the data is dominated by the "pregnant pause"
waiting for the printer's timer to expire.  In the case of a BSD4.2 system,
the default for tcp_sendspace is N=2048, so the throughput is close to
4 Kbytes or 32 Kbits/second.

The fix is to increase the sender's buffer space such that the send buffer
space is as great as the offered window (N >= M).  This ensures that the
printer will send an ACK when it receives all the data the host is able to
send.

As mentioned above, the bug is fixed in IMAGEN's V3.3 software.

- Geof Cooper
  IMAGEN

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jul 86 15:25:24 pdt
From:      John B. Nagle <jbn@glacier.stanford.edu>
To:        mod.protocols.tcp-ip
Subject:   Re: Re: RING vs. ETHER - Theory and practice.
      1.  If you are losing packets due to having too few
	  receiving buffers in your Ethernet controller,
	  get a modern Ethernet controller.  The worst known
	  offender is the old 3COM Multibus Ethernet controller
	  used in early SUN systems; not only does it have only
	  two receiving buffers, it has no overrun detection, and
	  thus the software never tallies the many packets it tends
	  to lose.  

      2.  If you are losing packets due to congestion problems in a
	  TCP-based system, this can be fixed; see my various RFCs
	  on the subject.  "Improving" the protocol by adding extra
	  acknowledgements or fancier retransmission schemes is
	  NOT the answer.  I've developed some workable solutions
	  that are documented in RFCs and implemented in 4.3BSD.

      3.  The real need for link-level acknowledges, or at least
	  some indication of non-delivery that works most of the
	  time, is for routing around faults.  Ethernets transmit
	  happily into black holes; when the destination dies,
	  the source never knows.  
	  When the destination Ethernet node is a gateway,
	  and said gateway goes down, there is no low-level way for
	  the sending Ethernet node to notice this and divert to an
	  alternate gateway.  This is a serious problem in hi-rel
	  systems, because we have no standard way for a host on
	  a multi-gateway Ethernet to behave which will cause it
	  to divert from one gateway to another when one gateway
	  fails.   There are a number of approaches to this
	  problem, all of them lousy:

	  - Ignore it and put up with at least minutes and perhaps
	    indefinite downtime when a supposedly redundant gateway fails.
	    (Considered unacceptable in military systems)
          - Shorten the ARP timeout to 10 seconds or so and spend
            excessive resources sending ARPs.
 	    (Tends to cause one retransmit every 10 seconds due
	    to non-clever ARP implementations).
          - Let the hosts participate in some kind of nonstandard
	    routing protocol so they can tell when a gateway dies.
	    (No good for off-the-shelf hosts).
	  - Let the transport layer inform the datagram layer when
	    a retransmit occurs, so that the datagram layer can trigger
     	    the selection of a different gateway; if this causes
	    selection of an up but ill-chosen gateway, a redirect
	    from that gateway corrects the situation.  (Some code
	    to do this is in 4.2BSD, but it wasn't fully implemented.)

	  It's all so much easier if you have link-level failure-to
	  deliver indications.

					John Nagle

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Jul-86 15:48:24 EDT
From:      cam@ACC-SB-UNIX.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Directory manipulation support in server FTP's

User FTP on our BSD 4.2 system supports some "experimental"
commands: pwd, mkdir, and rmdir.  Use of these commands results
in XPWD, XMKD, or XRMD being sent to the FTP server.  The
BSD 4.2 server recognizes and handles these commands appropriately.
As far as I know, this is vanilla 4.2 operation; we have not modified
User or Server FTP in our system.

Appendix II in the latest FTP RFC (RFC959) specifies that PWD, MKD, 
and RMD should be sent to an Server FTP to request the appropriate 
directory operation.

Does BSD 4.3 support the commands in Appendix II of RFC959? 
Does it also remain compatible with 4.2 by supporting the X... 
versions of the commands? Where do other FTP servers stand in 
respect to support for the directory commands
(MKD, PWD, RMD, CDUP) specified in Appendix II of RFC959?
Do any other servers support the X... "experimental" commands?

If anybody is familiar with 4.3 FTP operation or the FTP operation 
of other FTP Servers and could comment on these questions, I would
certainly appreciate it.  Thanx.

Chris Markle (cam@acc-sb-unix.arpa 301-997-9373)

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Jul-86 18:25:24 EDT
From:      jbn@GLACIER.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Re: RING vs. ETHER - Theory and practice.


      1.  If you are losing packets due to having too few
	  receiving buffers in your Ethernet controller,
	  get a modern Ethernet controller.  The worst known
	  offender is the old 3COM Multibus Ethernet controller
	  used in early SUN systems; not only does it have only
	  two receiving buffers, it has no overrun detection, and
	  thus the software never tallies the many packets it tends
	  to lose.  

      2.  If you are losing packets due to congestion problems in a
	  TCP-based system, this can be fixed; see my various RFCs
	  on the subject.  "Improving" the protocol by adding extra
	  acknowledgements or fancier retransmission schemes is
	  NOT the answer.  I've developed some workable solutions
	  that are documented in RFCs and implemented in 4.3BSD.

      3.  The real need for link-level acknowledges, or at least
	  some indication of non-delivery that works most of the
	  time, is for routing around faults.  Ethernets transmit
	  happily into black holes; when the destination dies,
	  the source never knows.  
	  When the destination Ethernet node is a gateway,
	  and said gateway goes down, there is no low-level way for
	  the sending Ethernet node to notice this and divert to an
	  alternate gateway.  This is a serious problem in hi-rel
	  systems, because we have no standard way for a host on
	  a multi-gateway Ethernet to behave which will cause it
	  to divert from one gateway to another when one gateway
	  fails.   There are a number of approaches to this
	  problem, all of them lousy:

	  - Ignore it and put up with at least minutes and perhaps
	    indefinite downtime when a supposedly redundant gateway fails.
	    (Considered unacceptable in military systems)
          - Shorten the ARP timeout to 10 seconds or so and spend
            excessive resources sending ARPs.
 	    (Tends to cause one retransmit every 10 seconds due
	    to non-clever ARP implementations).
          - Let the hosts participate in some kind of nonstandard
	    routing protocol so they can tell when a gateway dies.
	    (No good for off-the-shelf hosts).
	  - Let the transport layer inform the datagram layer when
	    a retransmit occurs, so that the datagram layer can trigger
     	    the selection of a different gateway; if this causes
	    selection of an up but ill-chosen gateway, a redirect
	    from that gateway corrects the situation.  (Some code
	    to do this is in 4.2BSD, but it wasn't fully implemented.)

	  It's all so much easier if you have link-level failure-to
	  deliver indications.

					John Nagle

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 1986 1540-PDT (Thursday)
From:      Jeff Mogul <mogul@navajo.stanford.edu>
To:        bjp@mitre-bedford.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Mysterious ARP behavior on a tcp-ip ethernet
[To summarize bjp's problem: he's got hosts sending out ARPs asking for the
 hardware address of IP host 192.12.120.255, and he wants to know why a host
 would ARP for what is supposed to be a broadcast address.]

Your problem is that you have two groups of hosts with different ideas about
what a broadcast address is.  One group follows RFC919 and uses "all ones"
for broadcast; these are the "good hosts".  The other group uses the "all
zeros" address that Berkeley put into 4.2BSD; these are the "bad hosts".
[Note that 4.3BSD is "good".]  "Good hosts" know that there are bad hosts
out there and recognize, but never transmit, all-zeros broadcasts; that is
why they are not trying to ARP the 192.12.120.0 address that the bad hosts
are probably broadcasting to.

So, what you should do is determine which of your hosts are "bad" (any host
that sends an ARP request for 192.12.120.255 is bad; you might have others.)
Then, call up the manufacturers and demand that they fix their code to
conform to RFC919.  If you are running 4.2BSD on a Vax, switch to 4.3BSD.

Whatever you do, NEVER EVER modify ARP code to respond to requests
for what turns out to be a broadcast address.  Ever.  Never, ever.
Not "hardly ever"; never.
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31-Jul-86 17:14:23 EDT
From:      cetron@UTAH-CS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Directory manipulation support in server FTP's


	i just checked my 4.3 bsd ftp/ftpd  and apparently they both
support MKD, PWD, RMD, CDUP  as well as  their X equivalents: XMKD, XPWD, XRMD,
and XCUP....
cheers
-ed

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31-Jul-86 18:40:00 EDT
From:      mogul@NAVAJO.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Mysterious ARP behavior on a tcp-ip ethernet

[To summarize bjp's problem: he's got hosts sending out ARPs asking for the
 hardware address of IP host 192.12.120.255, and he wants to know why a host
 would ARP for what is supposed to be a broadcast address.]

Your problem is that you have two groups of hosts with different ideas about
what a broadcast address is.  One group follows RFC919 and uses "all ones"
for broadcast; these are the "good hosts".  The other group uses the "all
zeros" address that Berkeley put into 4.2BSD; these are the "bad hosts".
[Note that 4.3BSD is "good".]  "Good hosts" know that there are bad hosts
out there and recognize, but never transmit, all-zeros broadcasts; that is
why they are not trying to ARP the 192.12.120.0 address that the bad hosts
are probably broadcasting to.

So, what you should do is determine which of your hosts are "bad" (any host
that sends an ARP request for 192.12.120.255 is bad; you might have others.)
Then, call up the manufacturers and demand that they fix their code to
conform to RFC919.  If you are running 4.2BSD on a Vax, switch to 4.3BSD.

Whatever you do, NEVER EVER modify ARP code to respond to requests
for what turns out to be a broadcast address.  Ever.  Never, ever.
Not "hardly ever"; never.

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1-Aug-86 00:08:16 EDT
From:      bjp@MITRE-BEDFORD.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Mysterious ARP behavior on a tcp-ip ethernet


	I am looking to see if anyone out there can give me some information
on what might be going on with our network.  We have a 500 meter ethernet
cable hooking together several sun workstations, a pc, a couple of Celerities,
random other machines, an appletek bridge that gets us to a broadband
cable with much else on it.  TCP/IP are the networking protocols used and arp
is used for address translation of IP internet addresses to 48 bit ethernet
addresses.  Some folks noticed bursts of ethernet broadcast messages
recieved by an IBM PC that occured at intervals sometimes 15 seconds,
sometimes 1 minute appart.

	I took a nutcracker and examined the traffic and took samples of the
traffic including bursts of broadcast packets.  I captured 128 octet slices
of each packet in the traffic sample.  I disassembled the hex codes to
identify MAC frame fields and their contents, including the data field where
I found either ip header info, or arp header info.

	Here is what I found.  There were about 30 packets in each burst.
Each was an arp request packet sent by a particular host looking for the
ethernet address for 192.12.120.255 (255 is a reserved assigned number
when in the host field means all hosts on 192.12.120, which is our network,
mitre-b-net).  This looked absurd - arp broadcasting to seek the ethernet
address of what looked to me like an Internet style broadcast address
for our network.  Without fail this burst of arp mischief was preceded
with an ethernet broadcast packet with an ip packet in its data field whose
source address was either one of two guilty hosts and whose destination
address was 192.12.120.255.  One of the hosts is our gateway to the
arpanet, milnet and many other wonderful places in the world.

	The plot thickens.  I examined the translation tables on several hosts
and found the internet address 192.12.120.255 with a big ? where an ethernet
address would have been if arp had a sensible internet address for a specific
target host to work with.

	Does anyone know why IP would do such a thing.  Is this how IP
forwards? If this is legitimate forwarding then why do arps do silly
things with it?

					bj Pease

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1-Aug-86 01:24:02 EDT
From:      HEDRICK@RED.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Mysterious ARP behavior on a tcp-ip ethernet

It is fairly common to get large-scale ARP'ing when there are confusions
on your network about hosts.  In general, I agree with Jeff Mogul.
However this is common enough that I'd like to add a bit of detail.  I
also have some suggestions to allow you to improve things without
getting every vendor to fix their implementation immediately.

First, let's get clear about what is happening.  One of your hosts is
sending a broadcast.  Since your network number is apparently
192.12.120, it is using 192.12.120.255.  This is the new standard: To
make a broadcast address, stick all ones in the host field.  (255 is all
ones.) Unfortunately, you have hosts on your network that believe that a
broadcast address should be made by sticking a zero in the host field,
i.e. 192.12.120.0.  When they see the packet addressed to
192.12.120.255, they think you are trying to address some specific host
with that address.  Since they are not that host, they decide to be nice
and forward the packet to the host.  In order to forward the packet,
they need the Ethernet address of 192.12.120.255.  Thus they issue an
ARP request for it.  The entry in the ARP table marked with ? means that
they have issued an ARP request but not yet gotten a response. 

In my opinion, the simplest solution is to continue using the old
convention on all machines until the new convention has been implemented
everywhere.  As Jeff points out, new implementations are being designed
to accept either.  Most new implementations allow you to set the
broadcast address that they will emit. So my suggestion is that you try
to get up to date implementations as soon as possible, but until you do,
set all the new implementations to use 192.12.120.0 as their broadcast
address.  Once everything is updated, then change over to using the new
convention on all your machines.

There is one more point.  It is really a mistake for normal machines to
forward packets that are intended for other machines.  This is happening
because almost every IP implementation has the potential for acting as a
gateway between two networks.  Such a gateway is expected to forward
packets from one network to the other.  Most of the code simply checks
to see whether the packet is for it, and if not, sends it on to the
destination.  This isn't a terribly clever approach, and real gateways
are generally more careful.  But when your machines isn't acting as a
gateway, forwarding packets at all is a bad idea.  It can gain nothing,
and when confusion occurs, things like you observed happen.  Most
implementations allow you to disable this forwarding.  In 4.2, you
simply set a variable ipforwarding to 0.  This can be done in adb even
if you don't have source.   Even this isn't ideal, because your machine
will send an error message back to the source of the packet telling it
that the packet couldn't be delivered.  We disable forwarding more
drastically. In routine ip_forward, we simply discard the packet.
(There is a test at the beginning of the routine checking whther the
packet is a broadcast.  If so, it is thrown away.  Just make that test
always succeeed.)  But even if you don't do this, turning off
ipforwarding will be a big help.  Every time the system sees a stray
packet, it will send back an error to the sender, rather than issuing an
ARP.  An ARP is a broadcast, so it clogs up everybody. The error will
just clog up the guy who is causing the problem.

Note, by the way, that the Applitek bridge in effect turns the whole
set of Ethernets that it connects into a single logical Ethernet. 
Depending upon how you have allocated Internet addresses, you may hve
to make sure that every host on every Ethernet connected via the
Applitek system is doing things consistently.
-------

END OF DOCUMENT