The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1984)
DOCUMENT: TCP-IP Distribution List for February 1984 (74 messages, 47547 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1984/02.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1984 1157 PST
From:      Eric P. Scott <EPS@JPL-VLSI>
To:        TCP-IP@SRI-NIC
Subject:   When a stranger knocks...
We changed our official name and address yesterday; this had some
amusing effects on SMTP servers.

Most didn't seem to mind, e.g.

220 UCB-VAX.ARPA Sendmail 4.22/4.21 ready at Wed, 1 Feb 84 19:15:25 pst
HELO JPL-VLSI.ARPA
250 UCB-VAX.ARPA Hello JPL-VLSI.ARPA, pleased to meet you
QUIT
221 UCB-VAX.ARPA closing connection

[I discovered that FUZZBALLs match the first three characters of
SMTP commands, e.g. HELP gives a 250 reply.]

BRL was perfectly calm until I QUIT...

220 brl Server SMTP (Complaints/bugs to:  MMDF@BRL-BMD.ARPA)
HELO JPL-VLSI.ARPA
250 brl
QUIT
221 brl says goodbye to 10.3.0.54 at Wed Feb  1 22:23:40 .

...but a number of TOPS-20 sites complained sooner:

220-SU-SCORE.ARPA SMTP Service 5.3(161) at Wed 1 Feb 84 19:07:23-PST
220 Bugs/Gripes to Bug-MAISER@SU-SCORE.ARPA
HELO JPL-VLSI.ARPA
250 SU-SCORE.ARPA - You are a charlatan, [10.3.0.54]
QUIT
221 SU-SCORE.ARPA Service closing transmission channel

One REAL LOSER was UCI-750A.  After a long pause:

521 Mail system claims 10.3.0.54 is an unknown host

No CRLF followed the text; the connection closed immediately.

Just the facts, ma'am.
					-=EPS=-
------
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Thu 2 Feb 84 14:21:34-PST
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        EPS@JPL-VAX.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: When a stranger knocks...
     The TOPS-20 SMTP server validates addresses vs. claimed
names, but will still accept the HELO command.  Note that Score's
SMTP server responded with a 250.  It will note the discrepancy
in the "Received" RFC 822 header line in a command, as in:
	Received: from JPL-VLSI.ARPA ([10.3.0.54]) by SU-SCORE with TCP; Thu 2 Feb 84 11:59:48-PST
but otherwise will allow the mail through.

     "You are a charlatan" means that the claimed name was known
on a different address; "never heard of you" means the claimed
name is unknown.

     The TOPS-20 mailsystem considers bracketed host addresses
(as in [10.3.0.54]) to be completely equivalent to host names and
in fact it can't tell the difference in most places.

-- Mark --
-------
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      02 Feb 84 16:04:15 PST (Thu)
From:      Network Services (agent: Marshall Rose) <netser@uci-750a>
To:        EPS@Jpl-Vax
Cc:        TCP-IP@Sri-Nic, Reply Distribution List: ;
Subject:   Re: When a stranger knocks...
    I must take some issue with your description of one of our hosts.
    I realize that your report was intentionally humorous (at least
    that's how I read it), but I think you touched upon a legitimate
    issue, while you were calling us names.

	One REAL LOSER was UCI-750A.  After a long pause:
	521 Mail system claims 10.3.0.54 is an unknown host
	No CRLF followed the text; the connection closed immediately.

    At the bottom of the message, I have an explanation as to why we
    didn't know who you were, but it's a digression, so I'll skip it
    for now.

    I object though to the term "loser".  As far as we know, 10.3.0.54
    is ficticious.  It's not in any of OUR host tables which was
    updated from the NiC's copy 1 week ago.  Why should we accept mail
    from you?

    UCB-VAX is running SendMail which couldn't care less about the mail
    it gets.  It is not "secure" in the sense that it does not do
    authentication of the sender.  

    BRL is running a later version of MMDF than we are and has what I
    would imagine to be a much better server that the UCI counterpart.
    My guess is that their server tells the mail system that you are
    10.3.0.54 and the mail system uses that and not the name you gave
    it.  Apparently, the server does not take it as given that your
    name really is JPL-VLSI.  I applaud the efforts of the MMDF people
    to try and make MMDF very "secure".  MMDF does lots of
    authentication checking.  They treat mail very seriously [my
    personal opinion, flames to me, not them].

    MRC's TOPS-20 server also knows that you aren't who you say you
    are, but says it up front, before you do anything else.  I don't
    know what Mark's implementation does, since I'm not familiar with
    it, but I'd guess that it uses 10.3.0.54 instead of JPL-VLSI.

    We are running one of the earliest versions of MMDF, which has been
    modified quite a bit to use SMTP and act 822-ish.  The long pause
    is due to the fact that we search many host tables looking for
    "10.3.0.54" (which we aren't going to find) and also because that
    system is always heavily loaded.  As far as the lack of a CRLF
    goes, that's a typo.  I've fixed it.

    You might claim that because our server doesn't accept a connection
    when it can't determine the internet name of a host making the
    connection, that it doesn't meet the SMTP spec.  I disagree. If
    your host is not registered in the NiC's HOSTS.TXT file, we refuse
    to talk mail with you.  You are not an Internet site by "our
    definition".  Perhaps an Internet guru (listening JBP or PVM?) can
    clarify this for me.

    We had the same problem when we hooked into the Internet in
    December of last year.  Although we made it into the 26-Dec-83
    HOSTS.TXT, a lot of sites didn't start accepting mail from us until
    about mid-January.  I'm sure there are still a few hosts about that
    refuse to talk to us.

    Also, being new at all of this, can someone tell me how often I
    should be grabbing HOSTS.TXT from the NiC?  I've been doing this
    once every other week, but after reading the "ps" below, it seems
    that isn't enough.

    Thanks,

/mtr

ps:
    Why we didn't know who you were:

    On January 28th, I grabbed the 1-26-84 version of HOSTS.TXT from
    the NiC.  The entry for JPL-VAX was:

HOST : 26.3.0.54 : JPL-VAX,JPL-VLSI : VAX-11/780 : VMS :
	TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER,UDP :

    Just a few minutes ago, I grabbed the most "recent" HOSTS.TXT file
    from the NiC.  The date at the top STILL says 1-26-84, but the file
    has changed.  The version of the new file, according to the
    hostnames server is 328.  Sadly, I didn't check on the version of
    the other file dated 1-26-84.  Anyway, now the entry for JPL-VLSI is:

HOST : 10.3.0.54 : JPL-VLSI,JPL-VAX : VAX-11/780 : VMS :
	TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER,UDP :

    The address of a host called "NSWC-WO" has also changed between
    these two files with the same date.

    That explains why our host tables are supposedly 1 week out of
    date, despite the fact the date on the HOSTS.TXT file at the NiC
    hasn't changed.  Guilty.
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1984 1626 PST
From:      Eric P. Scott <EPS@JPL-VLSI>
To:        TCP-IP@SRI-NIC
Cc:        netser@UCI-750A
Subject:   When to update tables
I was under the impression that "the right thing to do" is to
send a VERSION request to the hostnames server (as part of a
daily procedure, for example) and retrieve the new tables if the
reply you get doesn't agree with the last one you remember.  Some
sites apparently never update their tables unless they get a mass
mailing from the NIC advertising the availability of a new set;
this is suboptimal behavior.  Many mailers have short attention
spans; after three days of non-delivery they give up.  "Can it
wait until Monday?"  "No!"  I get really ticked when I get
dropped from mailing lists because of temporary problems beyond
my control, often with no notification whatsoever.  When I notice
non-deliveries in our mailer log, I try to track them down.
Sometimes the 1822 host dead status is useful!  IP is wonderful,
etc., but if I have unnatural knowledge I use it.  If your
"secure" SMTP is going to be antisocial, it could at least notify
someone human that something bozo is happening.  Refusing to
accept traffic just strikes me as blatently wrong behavior.  I
stand by my value judgement.
					-=EPS=-
------
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      02 Feb 84 16:37:49 PST (Thu)
From:      Network Services (agent: Marshall Rose) <netser@uci-750a>
To:        EPS@Jpl-Vax
Cc:        TCP-IP@Sri-Nic, Reply Distribution List: ;
Subject:   Re: When to update tables
Thanks for the "version" tip.  I'll start using it in a "automated" fashion.
Actually, our mail server does tell us when something like that happens,
once a day.  Unfortunately, someone "stole" my status report listing last
night and I haven't generated a new one yet.  I really don't consider our
SMTP either "secure" or anti-social.  Cautious is a better term.  (-:

/mtr
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Thu 2 Feb 84 18:45:00-PST
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   "secure"/"anti-social"/"cautious" SMTP server
Any SMTP server which rejects mail because its (possibly out of date) host
tables cause a host name validation failure deserve to be called "losing".

I can think of a zillion ways to forge mail to such a server.  It is not
secure.

I seriously doubt that the server intentionally rejects mail in order to
inconvenience new hosts.  It is not anti-social.

A cautious approach would dictate accepting the message, as it could be
some critical message (e.g. funding information!); at most it should note
the host name validation failure as a comment.  The server in question is
not cautious.

If "losing" seems to be too personal, use "faulty" instead.  A faulty SMTP
server rejected a valid mail message from a site which validly stated its
valid name on its valid address.  The cause of the rejection was that the
faulty SMTP server uses the faulty and obsolete concept of host tables.
Only name server information should be considered current or trustworthy.

We live in a networking era of incomplete knowledge of network topology.
There are many sites at Stanford talking TCP which aren't in the NIC
table.  In general, most of those sites won't be sending mail to ARPANET
anyway.  But it doesn't mean that mail from such a site should necessarily
be rejected.

I wonder how many SMTP servers will accept a command such as:

	HELO [10.3.0.11]

(TOPS-20s will!).

-- Mark --
-------
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      02 Feb 84 23:21:18 PST (Thu)
From:      Network Services (agent: Marshall Rose) <netser@uci-750a>
To:        Mark Crispin <MRC@Su-Score>
Cc:        TCP-IP@Sri-Nic, Reply Distribution List: ;
Subject:   Re: "secure"/"anti-social"/"cautious" SMTP server
[Watch closely and I will remove the foot from my mouth.]

I agree that faulty is a much better term, and I agree that uci-750a's
SMTP server is faulty at best.  However, you should think that I was
claiming that our SMTP server was "secure".  I made no advertisements
of that kind at all.  I was trying to explain, rather lamely, why it
did what it did.

/mtr
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Thu 2 Feb 84 23:57:57-PST
From:      David Roode <ROODE@SRI-NIC>
To:        wert.Rice@RAND-RELAY.ARPA, netser@UCI-750A
Cc:        EPS@JPL-VLSI, TCP-IP@SRI-NIC
Subject:   Re: When a stranger knocks...
On many hosts, users can reply to the ADDRESS even if the
HOSTNAME is not known to the system.  Thus they can slip around
lax system operators who do not update hostables rapidly.
Soon, we will have domain addressing with dynamic name resolution
and such concerns will not be relevant (knock on wood).
-------
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 84 21:16:21 EST
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        netser.UCI-750A@RAND-RELAY.ARPA
Cc:        EPS@JPL-VAX.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: When a stranger knocks...
Probably your message crossed Crispin's in the mail.  But in case you
didn't notice, Tops-20 does what I think is the optimal thing:
  1) it accepts the mail
  2) the response to HELO, although 250 (which indicates that it
	worked), gives a clear indication that something is wrong,
	so that someone can follow up.
  3) in the RECEIVED line, a comment is supplied giving the actual
	host address when it differs from what we think it should be.
	Actually I think my old code was better.  It said
		Received from [1.2.3.4] (claiming to be FOO.ARPA)

This message causes me to raise two other issues that have been sitting
in my mind waiting for an excuse:
  1) The protocol specified that user names must be validated. However
	as far as I can see there is no way to do that. We can verify
	the host from which it came, and Crispin's Tops-20 handles that
	fairly well.  But anyone at that site can open a connect to us
	and claim to be anybody he wants.  We prevent that on our
	Ethernet by having  the mail sender use a privileged socket. The
	mail  receiver refuses to talk to anyone who is not on a
	privileged socket.  This guarantees that we accept mail only
	from the real mailer on the other end.  We are able to use
	operating system facilities to make sure that the real mailer
	always gives a return-path that is the actual person who created
	the message.  Either the RFC's should drop the requirement that
	names be validated, or some mechanism like this should be made
	network-wide.  I realize that there will be systems where this
	doesn't make sense (e.g. ITS, where there is little security),
	or dialup implementations of TCP.  But at least we should be
	able to preserve the same degree of security that was present
	on the originating system.

 2) It might be helpful to have ways of reporting nonfatal problems.
	E.g. for problems on the sending side, the receiver could
	use a response meaning	"this operation succeeded, but it
	probably shouldn't have". This would cause the mail system at
	the other end to make an entry in an exceptions log, send mail
	to the maintainer, or something else appropriate.  Then we could
	acknowlege a HELO by:
	    251 You are internet [1.2.3.4].  You claim to be FOO.ARPA.
	    251-According to our records you are not.
	The sender should also be able to do this, presumably via
	a new commands, something like EXCEPTION-REPORT:
	    EXCEPTION-REPORT
	    250 end with .
	    In delivering a message from FOO.ARPA to BAR.ARPA, FOO.ARPA
	    had to use 50-byte segments, pushed.  Something may be
	    wrong with your TCP.
	    .
-------
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Fri,  3 Feb 84 00:18:26 CST
From:      Scott Comer <wert@rice>
To:        Network Services (agent: Marshall Rose) <netser@uci-750a>
Cc:        EPS@Jpl-Vax, TCP-IP@Sri-Nic
Subject:   Re: When a stranger knocks...
It seems to me to be better to reject mail from an unknown host than to
accept mail from such a host and then have users (on the local host) get
mail from this machine and not be able to reply. This puts the
responsibility on the machine with the strange name to make sure everyone
knows its name, rather than on the unsuspecting users who got mail from a
bogus host.

Of course, this is just my opinion...
wert
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Feb 84 3:35:38 EST
From:      Mike Muuss <mike@brl-vgr>
To:        "Network Services (agent: Marshall Rose)" <netser@uci-750a>
Cc:        tcp-ip@sri-nic
Subject:   Fetching HOSTS.TXT from NIC
The strategy that we use at BRL is to download the NIC table to ONE
machine once a night (at 0400 EST), and redistribute it to all BRLNET
machine locally.  The procedure is entirely automated, and makes heavy
use of the UNIX RSH/RCP facility (Bravo, Berkeley!).

This procedure is called /etc/nightly, and in addition to updating
host tables, it also propagates changes in the "BRL global name space",
and causes fresh MMDF binary databases to be generated.
	-Mike
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Saturday,  4 Feb 1984 23:05-PST Friday,  3 Feb 1984 07:59-PST
From:      geof@Shasta
To:        shasta!TCP-IP@sri-nic.arpa
Cc:        geof@Shasta
Subject:   RE:When a stranger knocks...
I don't see why the desire for a ``secure mailer'' prevents a host from
accepting mail when the sender's host name is unknown.  After all we are
Receiving information, not sending it.  As long as the receiver of the mail
knows that the sender's identity is dubious, I see no reason to avoid
forwarding the mail to its destination.

I am arguing for an approach like that of Tops-20, where the unknown
identity of the sender is added to the mail header.  Actually, I think that
the (somewhat obscure) message that is presently placed there should be
more to the effect of:

	Security-Caution: THE IDENTITY OF THE HOST THAT SENT THIS MESSAGE
			  (name) DOES NOT CONCUR WITH ITS ADDRESS IN INTERNAL
			  TABLES (address).  PLEASE AVOID RELYING ON THE
			  AUTHENTICITY OF THE SENDER WITHOUT SEPARATE
			  VERIFICATION.

(alright, it's a little verbose, but who would overlook it?)

- Geof Cooper
  Imagen
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Feb 84 09:16 PST
From:      Taft.PA@PARC-MAXC.ARPA
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: When a stranger knocks...
Who says the host named in the HELO command has anything to do with the
domain of the message's originator? Validating the host name serves no
useful purpose. If you insist on validating anything, it should be the
return-path domain name given in the MAIL FROM command.

Arguments about security considerations in this context are absurd. The
ARPA Internet is an open system. "Validated" host names and "privileged"
sockets are meaningless and have no security benefit. The only way to
achieve secure communication in an open system is to use end-to-end
encryption.

	Ed Taft

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1984 1139 PST
From:      Eric P. Scott <EPS@JPL-VLSI>
To:        TCP-IP@SRI-NIC
Cc:        wert@Rice
Subject:   RTFM ("Read The Manual")
RFC 821 states:

  Sometimes a host is not known to the translation function and
  communication is blocked.  To bypass this barrier two numeric
  forms are also allowed for host "names".  One form is a decimal
  integer prefixed by a pound sign, "#", which indicates the
  number is the address of the host.  Another form is four small
  decimal integers separated by dots and enclosed by brackets,
  e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
  Address in four 8-bit fields.
					-=EPS=-
------
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Feb 84 11:40 PST
From:      Maron@LLL-MFE.ARPA
To:        tcp-ip@nic.arpa
Subject:   I need pointers to TCP/IP code
(1) I need to implement TCP/IP on PDP-11s using a home grown OS, i.e.
not RSX, RT, VMS , UNIX, etc.  etc.  Does anyone have any PD code either
in assembler (PDP-11) or C that I could get as a guide or to use fairly
directly?

(2) Please respond directly to me, I am not on the list.  I'm
MARON@LLL-MFE.

Thanks in advance,
--Neil Maron
CC:     tcp-ip@nic.arpa,
	Maron
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1984 1745 PST
From:      Eric P. Scott <EPS@JPL-VLSI>
To:        TCP-IP@SRI-NIC
Subject:   Query for Murphy's Lawyers
What do you do when something goes wrong with the network where
nothing *ever* goes wrong?  We're learning...
			      * * *
Our IMP connection is via a microwave link that isn't quite as
reliable as we'd like (you'd think JPL wouldn't have this
problem, especially at terrestrial distances).  Our 4.1cBSD-
derived software doesn't seem to care that the IMP Ready line has
gone away for an extended period of time.  How can I convince it
that the interface is unavailable?  A non-obvious (to me, anyway)
and somewhat elegant approach: capitalizing on the symmetry of
the 1822 Host Access Protocol, put our ECU in Local Loopback 2
and send a Type 2 (IMP going down in 30 seconds) message using
a "raw IMP" socket.  Half a minute later things are left in a
consistent state from which recovery will automatically occur
once the link is restored and a Reset is received.
			      * * *
Does anyone have a set of guidelines related to network fault-
finding?  Comments?

					-=EPS=-
------
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1984 21:23:31 PST
From:      MILLS@USC-ISID
To:        EPS@JPL-VAX, TCP-IP@SRI-NIC
Cc:        MILLS@USC-ISID
Subject:   Re: When a stranger knocks...
In response to the message sent  2 Feb 1984 1157 PST from  EPS@JPL-VLSI

Eric,

Oh gawrd, another one caught me! Fuzzies do, indeed, parse only the first three
characters of the command name. THey should, however, return what they think
is the current mapping between your host address and its apparent name from the
NIC tables. Unfortunately, they are a leetle bit behind in snarfing the
HOSTS.TXT, at least compared with the TOPSes.

Dave
-------
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      4 February 1984 12:58 EST
From:      David C. Plummer <DCP @ MIT-MC>
To:        MILLS @ USC-ISID
Cc:        TCP-IP @ SRI-NIC, EPS @ JPL-VLSI
Subject:   Re: When a stranger knocks...
    Date:  3 Feb 1984 21:23:31 PST
    From: MILLS@USC-ISID

    In response to the message sent  2 Feb 1984 1157 PST from  EPS@JPL-VLSI

BTW, folks.  What silly mail reading program is putting this
textual "In response to ... " in the body instead of using an
In-reply-to: field in the header?  I guess you've never used
	m-X Select Conversation by References
on a Lisp Machine... (BABYL may have something similar.)

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 1984 18:37:53 PST
From:      MILLS@USC-ISID
To:        DCP@MIT-MC
Cc:        TCP-IP@SRI-NIC, EPS@JPL-VAX, MILLS@USC-ISID
Subject:   Re: When a stranger knocks...
In response to your message sent  4 February 1984 12:58 EST

David,

I just use 'em, not build 'em. On TOPS-20s anyway. If you want to take
umbrage, wait until I send something from a fuzzball, which I do build. The
little fuzzthings would never do anything like stuff an "In reply" in the
text.

Dave
-------
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Sun 5 Feb 84 00:14:39-PST
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   mail security
     Let's end this discussion about mail security.  As Ed Taft pointed
out, secure electronic mail in the Internet context is impossible.  If
any user fantasizes that he cannot receive forged mail, or that his
outgoing (or incoming) mail cannot be read by anyone other than the
intended recipient, that user should be educated to the hard facts.

     All the TOPS-20 mailsystem's "security" features will do is to
assist a reasonably competant user in resisting undetected forged mail
(or unauthorized reading of private mail) in those cases where the
attack is initiated by a relatively unskilled vandal.  I wrote much of
the "security" code; it would not resist an attack by me or for that
matter from any other competant TOPS-20 system programmer who took the
time to familiarize himself with the mailsystem's internals.

     This isn't due to any Trojan horses introduced by me.  This is due
to the fact that Internet doesn't have any better support.  Mail security
is only as good as the least secure host.  That's pretty unsecure.  The
only "secure mail" possible involves end to end encryption between
trusted hosts.

     Let's drop this subject, and let's not hear "mail security"
presented or argued as a justification for faulty software.  There ain't
no such thing, and the sooner this is generally recognized the sooner we
can move to more productive issues, such as multi-media mail.
-------
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      06-Feb-84 04:29:02-UT
From:      Mills@dcn6
To:        tcp-ip@sri-nic
Subject:   An EGP one-act play
Folks,

The following longish message is offered as an example of the world seen by an
EGP gateway fighting the Packet Wars resulting from the various trash floating
about the Internet system. Ordinarily, I would send it (as I have sent many
similar previous messages) to the wizards to help in the casting of spells.
However, I think the TCP-IP community at large may gain an interesting insight
into the practical problems of day-to-day operation, as well as an
appreciation of the importance of isolating potential routing loops entirely
within an autonomous system.

Please note that some of the ills related here are due to bugs that can in
principle be quickly fixed. Others are due to the sheer size of the
core-gateway community, which has far outgrown the present GGP protocol. In
the "near" future GGP will be replaced by something more robust, so that the
disasterous "counting to infinity" problem should disappear. On the other
hand, routinge and congestion problems will probably be with us for some time,
so the lessons of the following may be relearned in many implementations.

OUR STORY

DCN-GATEWAY lives on a lonely EGP island in the midst of the GGP core-gateway
sea. The story you are invited to hear involves almost a day in its hard life
maintaining order for the Protocol Police.

CAST OF CHARACTERS

The Hero
DCN-GATEWAY	10.3.0.17	(aka DCN1) a good EGP soldier and teller
		128.4.0.1	of this tale
		128.5.0.1

The Villians
BBN-INOC	10.2.0.82	the internet monitor interface and speaker
				of most of the dialog
TEST3		10.3.0.63	the only EGP/GGP navigation aid in the area
BBN-VAN-GW	10.3.0.40	a flakeway in search of stability
		14.0.0.10

Shifty Characters
COLUMBIA-20	10.0.0.89	a rather dense character which talks a lot
				and learns nothing
SRI-NIC		10.0.0.51	a firehose hard to quench
RICE		14.0.0.12	a TELENET host, usually recognized as a black
				hole
CISL-SERVICE-MULTICS
		10.3.0.31	believed an EGP gateway embryo
		192.5.1.1

Incidental Players
FORD-WDL1	128.5.32.1	a Unixcorn hiding behind DCN-GATEWAY and
				a 9.6-Kbps piece of plumbing
UCB-VAX		10.2.0.78	a passerby
MIT-MC		10.3.0.44	mostly used by people with unscrewed heads

THE PLOT

DCN-GATEWAY receives its only routing information from TEST3 via EGP. When
a net or a GGP core gateway is killed in a skirmish, TEST3 tells DCN-GATEWAY
sooner or later, mostly later. The story opens with a backstage whisper
saying that somehow DCN-GATEWAY is the best route to TELENET. That seems
to unhinge BBN-INOC, which just can't seem to believe the truth, probably
because of an unstable routing loop within the core system.

THE SCRIPT

Stage directions: Ignore the octal process number following the time. The ICMP
lines in the script represent ICMP messages sent by DCN-GATEWAY. The two
octal numbers are the type and code, while the Internet addresses represent
the source and destination of the original datagram. Type 003 is destination-
unreachable, 004 is source-quench and 005 is redirect.

The Leader error lines represent 1822 host-dead messages and include the octal
leader exactly as received. 

The script, excerpted from the DCN-GATEWAY log, begins with about 30 minutes
of misrouted packets from BBN-INOC to the TELENET side of BBN-VAN-GW.
DCN-GATEWAY babbles redirects (presumably to 10.3.0.40) on and on, but
BBN-INOC isn't listening.

23:12:59 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
	... 178 duplicate(s) ...
23:41:44 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]

Now, this is very curious, since TEST3 should be biasing anything sent by
DCN-GATEWAY so that dialog within the core system should never, never escape
outside. Then BBN-VAN-GW apparently dies and things get worse (note the
byte-swapped leader reveals host 3 on IMP 40, which is one of the interfaces
of BBN-VAN-GW).

23:41:44 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:41:44 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:42:02 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:42:02 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:42:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:42:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:42:14 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:42:14 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:42:44 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:42:44 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:42:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:42:46 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:42:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:42:49 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:43:15 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:43:15 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:43:15 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:43:16 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:43:35 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:43:35 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:43:47 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:43:47 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:43:47 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:43:47 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:44:16 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:44:16 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:44:16 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:44:16 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:44:20 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:44:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:45:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
	... 277 duplicate(s) ...
23:51:53 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:51:53 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
	... 11 duplicate(s) ...
23:52:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:52:24 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:52:24 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:52:25 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:52:25 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:53:00 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:53:00 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:53:00 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:53:00 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:53:28 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:53:28 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
23:53:28 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:53:29 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
23:53:58 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
	... 495 duplicate(s) ...
23:58:09 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]

This spasm lasts for over 13 minutes, presumably being the time to count to
infinity in that nasty GGP babble. Finally, TEST3 tells DCN-GATWEWAY net 14 is
dead and things die down. BBN-INOC continues to sputter.

23:58:35 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
	... 20 duplicate(s) ...
00:07:59 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]

A few minutes later net 14 comes back up and the raunch resumes after only
5 minutes.

00:19:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:24:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:24:46 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:24:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:24:48 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:25:17 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:25:17 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:25:18 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:25:18 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:25:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:25:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:25:48 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:25:49 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:26:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:26:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:26:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:26:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:26:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:26:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:26:50 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:26:50 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:27:20 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:27:20 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:27:21 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:27:21 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:27:28 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:27:29 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:27:36 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12]
00:27:36 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:27:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:27:51 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:27:51 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:27:51 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:28:21 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:28:21 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:28:22 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
00:28:22 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633
00:28:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
	... 422 duplicate(s) ...
00:33:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]

That spasm, having lasted over 8 minutes, passes the same way as the previous
one.

00:33:30 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
	... 21 duplicate(s) ...
00:42:30 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]

Enter the clowns. Net 128.8 is off a dumb gateway on MILNET. How did
COLUMBIA-20 get here?

00:42:41 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]

Next, FORD-WDL1 attempts to FTP something from SRI-NIC, which sloshes
over all 26 buffers in DCN-GATEWAY. The latter bitterly complains
source-quenchedly, but SRI-NIC will have none of that truck.

00:56:30 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1]
00:56:30 006 ?TRAP-I-No buffer 2
00:56:42 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1]
00:56:43 006 ?TRAP-I-No buffer 2
00:56:47 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1]
00:56:47 006 ?TRAP-I-No buffer 2

TEST3 gets quenched, too (!). Later COLUMBIA-20 chimes again.

00:56:50 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17]
00:56:50 006 ?TRAP-I-No buffer 2
01:17:04 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]

A bit later COLUMBIA-20 and a friend begin hammering on FORD-WDL1
again. Buffers and quenches are dripping all over the place.

01:37:38 006 ?TRAP-I-ICMP 004 000 [10.0.0.31] -> [128.5.32.1]
01:37:38 006 ?TRAP-I-No buffer 2
01:39:11 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:11 006 ?TRAP-I-No buffer 2
01:39:12 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:12 006 ?TRAP-I-No buffer 2
	... 5 duplicate(s) ...
01:39:17 006 ?TRAP-I-No buffer 2
01:39:18 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:18 006 ?TRAP-I-No buffer 2
01:39:19 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:19 006 ?TRAP-I-No buffer 2
01:39:20 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:21 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:21 006 ?TRAP-I-No buffer 2
01:39:22 006 ?TRAP-I-No buffer 2
01:39:23 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:23 006 ?TRAP-I-No buffer 2
01:39:24 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:24 006 ?TRAP-I-No buffer 2
01:39:25 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:25 006 ?TRAP-I-No buffer 2
	... 2 duplicate(s) ...
01:39:27 006 ?TRAP-I-No buffer 2
01:39:28 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:28 006 ?TRAP-I-No buffer 2
01:39:29 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:29 006 ?TRAP-I-Link up
01:39:29 006 ?TRAP-I-No buffer 2
01:39:30 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:31 006 ?TRAP-I-No buffer 2
01:39:32 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:32 006 ?TRAP-I-No buffer 2
01:39:33 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
01:39:33 006 ?TRAP-I-No buffer 2
	... 3 duplicate(s) ...
01:39:36 006 ?TRAP-I-No buffer 2
01:39:37 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17]
01:39:37 006 ?TRAP-I-No buffer 2
01:43:57 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]

This mess, previously identified as an instance of the "runaway ACK" bug, has
been repeatedly reported to the COLUMBIA-20 wizards. As evident from the
above, it completely destabilizes any gateway in its path, not just
DCN-GATEWAY, that happens to have smaller than 56-Kbps pipes on the other
side. In the case of COLUMBIA-20 the bug has persisted for some weeks, at
least, and caused many, many spasms of the kind illustrated above.
Nevertheless, COLUMBIA-20 finally gives up. Meanwhile, CISL bobbles of unknown
causes, probably irrelevant here.

02:06:37 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
02:07:33 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
02:09:42 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
02:11:35 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]

What? Net 48 was removed from the NIC tables a month ago. Somebody needs
a HOSTS.TXT injection.

02:19:41 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [48.3.2.41]
02:41:40 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]

Net 14 comes unstuck again, but this time BBN-INOC is not the only one
fooled.

02:45:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
02:48:40 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12]
	... 34 duplicate(s) ...
02:48:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12]
02:48:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
02:48:50 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12]
	... 44 duplicate(s) ...
02:49:05 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12]
02:51:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
	... 355 duplicate(s) ...
02:54:37 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
02:54:38 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
02:54:38 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
	... 2 duplicate(s) ...
02:54:38 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
02:54:48 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
	... 21 duplicate(s) ...
03:03:51 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
03:09:14 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
03:10:10 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
03:11:51 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
03:20:23 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5]

Off we go again with net 14:

03:22:27 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
03:25:00 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
03:27:22 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12]
	... 95 duplicate(s) ...
03:27:42 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12]

The next one is legitimate. Bleeding continues after that:

03:27:43 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.3]
03:27:43 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12]
	... 2 duplicate(s) ...
03:27:43 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12]
03:28:02 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
	... 12 duplicate(s) ...
03:28:04 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
03:28:05 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12]
	... 2 duplicate(s) ...
03:28:05 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12]
03:28:05 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
03:28:06 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12]
	... 76 duplicate(s) ...
03:28:29 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12]
03:28:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
	... 24 duplicate(s) ...
03:28:36 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
03:28:43 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12]
	... 14 duplicate(s) ...
03:28:45 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12]
03:29:33 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
	... 149 duplicate(s) ...
03:31:39 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
03:32:36 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
	... 4 duplicate(s) ...
03:35:46 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
03:36:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
03:40:04 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
03:40:37 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [14.0.0.12]
	... 79 duplicate(s) ...
03:41:02 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [14.0.0.12]
03:41:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
03:42:41 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12]
	... 99 duplicate(s) ...
03:43:01 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12]
03:43:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
	... 156 duplicate(s) ...
03:49:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
03:49:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
03:49:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
03:49:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
03:50:21 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
03:51:27 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
03:51:44 006 ?TRAP-I-ICMP 003 000 [10.2.0.78] -> [14.0.0.12]
03:52:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
	... 9 duplicate(s) ...
03:58:43 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10]
04:08:45 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4]
	... 47 duplicate(s) ...
04:09:34 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4]
04:09:48 006 ?TRAP-I-ICMP 003 000 [10.2.0.78] -> [14.0.0.12]
04:12:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12]
04:12:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4]
04:13:10 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
04:16:05 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12]
04:41:05 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]

CISL wobbles and bobbles. COLUMBIA-20 continues to whack on net 128.8
the wrong way every half hour (probably mail):

04:49:41 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
04:50:38 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
04:56:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
04:57:17 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10]
05:10:13 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
05:39:38 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
05:52:53 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
05:53:51 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
06:09:29 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
06:42:58 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
06:57:08 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
06:58:05 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
07:12:56 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
07:42:58 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
08:00:12 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
08:01:10 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
08:12:55 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]

Somebody out there is fooling with the fuzzies. DCN2 and DCN3 are
asleep. After all, it is 3:30 in the morning. The carnage continues
sporadically and indefinately.

08:33:24 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.2]
08:33:32 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.3]
08:41:53 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.2]
08:42:57 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
09:03:09 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
09:04:06 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
09:12:56 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
09:42:54 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
10:05:49 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
10:06:47 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633

Just for fun, DCN-GATEWAY's line to the ARPANET IMP flaps.

10:12:16 006 ?TRAP-I-Leader error 000017 000400 000000 000000 001000
10:13:01 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
10:42:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
11:06:08 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
11:07:04 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
11:12:51 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
11:42:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
12:08:39 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
12:09:36 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
12:12:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
12:42:46 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
13:11:14 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
13:12:10 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
13:12:44 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
	... 2 duplicate(s) ...
14:12:45 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
14:13:50 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
	... 10 duplicate(s) ...
14:14:45 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633
14:42:45 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
15:12:43 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]

Finally, TEST3 dies as the curtain falls for the final time.

15:13:16 006 ?TRAP-I-Leader error 000017 003400 001400 037400 000233
	... 18 duplicate(s) ...
15:22:33 006 ?TRAP-I-Leader error 000017 003400 001400 037400 000233
15:23:04 006 ?TRAP-I-Leader error 000017 003400 001400 037400 000633

*** FIN ***

This play will never make it to Broadway. However, even the bombs have
morals:

1. How did any ARPANET host ever get the idea anything except 128.4 and
   128.5 were reachable via DCN-GATEWAY? DCN-GATEWAY is known under
   certain conditions to fib about routing, but these conditions did
   not hold here. In any case, TEST3 should not believe any path outside
   the core system is shorter than any path inside.

2. Assuming the rash of misrouted packets from BBN-INOC was due to unstable
   routing information which existed while the system counted to infinity,
   note the terribly long time it takes to again reach stability - from
   a few minutes to twenty minutes or more in previous scenarios.

3. Much of the carnage illustrated in the play was apparently due to the
   BBN-VAN-GW gateway bobbing up and down. If we get many more gateways
   doing that kind of thing, it could happen that the entire gateway
   system could self-destruct and assume a pathological state where infinity
   would never be reached.

4. How can rogue hosta like COLUMBIA-20, which are second only to pingers
   as network disrupters, be politely but firmly repulsed until repaired?
   The runaway-ACK problem is probably the worst kind of thing that any
   host anywhere can do.

Dave
-------
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      7-Feb-84 07:53 PST
From:      Bill Barns  <WWB.TYM@OFFICE-2>
To:        tcp-ip@sri-nic
Subject:   Martian Attack on OFFICE-8
The SMTP server logs for host OFFICE-8 [26.0.0.93] show attempted connections 
from the same Martians referred to in the message of 07-Feb-84 05:22:33-UT from 
<mills@dcn6>, namely [97.128.13.75].  The connections failed to open up 
properly, as you might imagine.  These connections began occurring on 30 Jan 84 
13:15:53 PST and ended after 2 Feb 84 23:05:44 PST, ranging from about 14 
minutes 48 seconds apart to 15 minutes 20 seconds apart, with about three 
15-minute cycles skipped over entirely.

The meaning of this is unknown to me.  I find it interesting that the Martians 
are contacting us on the SMTP port.  They must be on Jon Postel's RFC mailing 
list.

I presume that every time OFFICE-8 tried to do its part of the TCP opening 
sequence, events similar to those cited for CMU-GATEWAY and DCN-GATEWAY probably
occurred.  I don't understand (and don't currently wish to understand) how all 
these things work at the protocol level, so I cannot interpret the meaning of it
all.  It does seem that it would be interesting to find out where the "Martian" 
datagrams are really coming from.  It also seems that there is some value in 
distributing widely such implementation esoterica as the Mills messages.  In 
this case it reassures me that my SMTP is not hallucinating and there really are
such datagrams out there in the network.  -b

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Tue 7 Feb 84 12:26:35-PST
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   ICMP source quench
TOPS-20 TCP/IP, as distributed by DEC, does not implement Source Quench.
I thought this was well known.  Any time you have a TOPS-20 doing battle
with a network that wants Source Quench you are going to lose.

If ISI has written code to support Source Quench this would be the first
that I have heard of it.  Certainly ISI has taken no trouble to publicize
the fact.  If some kind ISI person would provide me with their code, I
would be happy to do the work of translating it to DEC TOPS-20 and
publicizing it further.

TOPS-20's have a pre-set gateway table.  It "pings" all pre-set "prime"
and "dumb" gateways periodically, as this is the only way it can tell if
a gateway is safe to use (let's hear it for this and other older and
dumber implementations of TCP!).  It assumes that all "always-up"
gateways are "always up" and that silence from that gateway doesn't
imply it is down.

Now that I've described the stage, let's enter two of the stage designers
who Dave has overlooked.  One is the NIC, the other are the nice people
who bring us gateways.

In theory, it suffices for a host to only have two Prime gateways wired
in.  This has been demonstrated to NOT be the case.  Repeatedly, TOPS-20s
have discovered that there are gateways in the NIC INTERNET.GATEWAYS table
which are NOT known to Prime gateways.  So we must argue that there is a
definite communication problem between the NIC and the gateway maintainers
as to what are gateways on Internet.

Next, the NIC evidentally refuses to provide an INTERNET.GATEWAYS table
which is useful; that is, a table which contains only the gateways which a
site needs to have pre-wired in.  Nominally the table would only contain
a few Prime gateways (implying a set of tables, with each site assigned to
take a particular one) and those gateways not known to Prime gateways.
The latter set of gateways should normally be empty, but let's say there
is a problem in the gateways.

I would like to hear why the NIC won't do this.  All too many sites just
take the full NIC INTERNET.GATEWAYS table and install it.  They don't know
any better, and some of them can't be taught any better.
-------
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 1984 1258 PST
From:      Eric P. Scott <EPS@JPL-VLSI>
To:        TCP-IP@SRI-NIC
Cc:        WWB.TYM@OFFICE-2
Subject:   Re: Martian Attack on OFFICE-8
I suspect the Martians have INTERLANded somewhere in the Berkeley
hills...
					-=EPS=-
------
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      07-Feb-84 05:22:33-UT
From:      mills@dcn6
To:        tcp-ip@sri-nic
Subject:   A short story
Folks,

After that bomb I dropped last night, I am hesitant to inflict more pain. With
the kind help of Mike Brescia and Eric Rosen we may have found one reason for
the hemorrhage of BBN-INOC redirects noted. To tell you true, DCN-GATEWAY may
have contributed something to the mayhem itself; however, that is now fixed
and swept quietly under the rug. The other problems remain.

I have pondered whether sequels to my one-act play serve a useful purpose
distributed to the entire tcp-ip list and concluded that the lessons learned
may be useful to the implementors in general. Please understand that I am not
trying to lob grenades (a few hit me, in fact) or make unneccesarily
disparaging remarks. I am trying to good-naturedly flush some of the Bad
Packets washing ashore on my island and in the process understand some of the
nonsense that can happen in a community such as ours.

Today, a short story. The players include a wanderer MIT-TAC (10.2.0.77) who
shuffles on and then off the stage causing no lasting impression. The heavies
include CMU-GATEWAY (10.2.0.14), who tries to call a friend on Mars
(97.128.13.75) every half hour, but DCN-GATEWAY has no wires to that space.
COLUMBIA-20 (10.0.0.89), RUTGERS (10.2.0.58) and AIDS-UNIX (10.2.0.56) appear
to have DCN-GATEWAY wired in as the way to UMDNET (128.8), but that net has
hidden behind a VAX on MILNET since early January, a fact well known to the
core gateways. Here is a specimen from the DCN-GATEWAY log (Typ 003 is
destination-unreachable, Typ 005 is redirect).

Time (UT) 6-7 Feb         Typ Cod   From            To
------------------------------------------------------------
19:03:26 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5]
19:13:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4]
	... 3 duplicate(s) ...
19:13:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4]
19:15:30 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4]
	... 2 duplicate(s) ...
19:15:39 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4]
19:15:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]
19:24:14 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
19:24:36 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
19:39:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
19:55:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
19:55:15 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]
19:55:42 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
20:12:19 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
20:20:03 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
20:25:31 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
20:37:44 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]
20:40:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65]
	... 7 duplicate(s) ...
20:40:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65]
20:53:16 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
20:55:06 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
20:55:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
21:06:31 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]
21:24:43 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
21:25:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
21:36:55 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
21:55:16 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
21:55:35 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
22:09:58 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]
22:20:30 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
22:25:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
22:25:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
22:38:31 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]
22:55:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
22:55:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
23:05:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
23:10:27 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
23:26:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
23:35:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5]
23:40:24 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
	... 5 duplicate(s) ...
01:28:17 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
01:46:25 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4]
	... 3 duplicate(s) ...
01:49:21 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4]
02:01:49 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
02:02:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
02:20:34 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
	... 6 duplicate(s) ...
02:22:21 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
02:32:45 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]

The Protocol Police would probably class these as misdemeanors. Now we add
SU-SCORE (10.3.0.11) to COLUMBIA-20 (10.0.0.89) on the list of Firehose
Felons. Following is a record of the ICMP source-quench messages sent to
SU-SCORE during a recent instance (host 128.5.32.1 is at our back door
connected via 9.6-Kbps line).

Time (UT) 6 Feb           Typ Cod   From            To
------------------------------------------------------------
20:02:43 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
	... 21 duplicate(s) ...
20:03:15 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
20:03:16 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17]
20:03:19 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
	... 9 duplicate(s) ...
20:03:30 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
20:03:31 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17]
20:03:32 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
	... 17 duplicate(s) ...
20:03:54 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
20:03:56 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17]
20:03:57 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
	... 8 duplicate(s) ...
20:04:09 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
20:04:11 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17]
20:04:12 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
	... 19 duplicate(s) ...
20:04:36 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
20:04:37 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17]
20:04:38 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
	... 12 duplicate(s) ...
20:04:53 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
20:04:56 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17]
20:04:58 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
	... 20 duplicate(s) ...
20:05:25 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
20:05:26 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17]
20:05:27 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
	... 9 duplicate(s) ...
20:05:37 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]

Note how the TEST3 (10.3.0.63) EGP gateway got trapped in that wash. I was
watching the "ready-for-next-bit" light on our ECU during this spasm, from
which it was apparent that the IMP was blocked for darn near three minutes.

DCN-GATEWAY sends a source-quench when the number of free buffers falls below
a threshold (currently two), hopefully before packets have to be dropped. Only
a few hosts (fuzzballs among them) actually do something with source-quench.
The fuzzballs keep careful track of the number of packets "outstanding" on a
TCP connection and enforce an upper limit (currently 8) which is throttled
back when a source-quench is received. We have learned that, without these
controls we cannot build a stable network of multi-diameter plumbing.

The firehose bug illustrated above with SU-SCORE, previously found with
COLUMBIA-20 and suspected with several other TOPS-20s (but not those at ISI),
could be due to naive retransmission controls or the "runaway-ACK" bug noted
previously. From prior experience the culprit is probably the latter, which
is known to quickly and completely distroy any gateway in its path.

Dave
-------
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 1984 13:49-PST
From:      Joel Goldberger <JGoldberger@USC-ISIB>
To:        MRC@SU-SCORE
Cc:        TCP-IP@SRI-NIC
Subject:   Re: ICMP source quench
ISI has no code to obey Source Quench ICMP msgs.  Like most other TCP
implementations (as reported at the most recent Internet Research Group
Meeting) we simply count their occurance.  What ISI does have is a
hardened IP/TCP as compared to that offered by DEC, or the older versions
of the original BBN code.  This is the result of folks like Dave Mills
beating up on us to get things right, and Charlie Lynn (of BBN) and Dale
Chase (of ISI) attacking specific problems as they have arisen (like the
runaway ACKs).  We have very extensive monitoring and tracing facilities
installed in our system that has been of great help in isolating and
correcting many of the problems Dave has uncovered.  All of the
corrective measures and bugfixes have been returned to BBN, and Charlie
Lynn is currently working with DEC to get them all back into the DEC
distributed version.

As to the gateway questions; this is an issue that I believe was beaten
to death recently enough that it should be dropped.  BBN is busily at
work on improving the general gateway situation through the use of EGP
and changes in the core (prime) gateways.  There was an announcement at
the INRG meeting that dumb gateways would have to implement EGP within
the next six months.  This will insure that all legitimate gateways can be
discovered, which is not the case now.  BBN also recognizes the problems
of GGP, which is the mechanism that the PRIME gateways use to maintain
all their routing information.  It simply doesn't work well as the
number of gateways increases.  As a point of information it was reported
at this meeting that GGP amongst the 22 Arpanet and 8 Milnet gateways
was responsible for 225K packets/hour.

- Joel Goldberger -
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 1984 15:51:52 PST
From:      MILLS@USC-ISID
To:        MRC@SU-SCORE, TCP-IP@SRI-NIC
Cc:        MILLS@USC-ISID
Subject:   Re: ICMP source quench
In response to the message sent  Tue 7 Feb 84 12:26:35-PST from MRC@SU-SCORE.ARPA

Mark,

I won't comment on the NIC issue. As for the TOPS-20s, I have been beating
especially on ISID for as long as there was a TCP (over five years) using
my haywire kit of leaky plumbing and know it well. So far as I know it
and all other TOPS-20s and VAXen (exception: FORD-WDL1, which was
locally massaged) disregard source-quench.

It has generally been the case that gateways with a couple of dozen packet
buffers can manage pretty well, even with mismatched pipes an order of
magnitude apart. This is normally the case with DCN-GATEWAY, which hides
perhaps two dozen active hosts behind it, some connected by pipes as low
as 1200 bps. However, an especially agile typist can sometimes nudge
a TOPS-20 to fill up all the buffers for echoes on the way back to
one of these hosts, for example. With FTP and mail things generally go pretty
well.

The problems I reported are believed to be due to bugs in the host
implementations. The "runaway-ACK" problem in particular just breaks everything
in sight. Ill-advised TCP retransmission timeouts also break things, but not
nearly so badly. I have observed several times today, for example, that hosts
trying to send mail to DCN6 (connected via 4.8-Kbps pipe) appear to initialize
their trx timeout as low as one second, which is clearly way too low
for any path not confined to the ARPANET.

It is not clear whether some "correct" implementation of source quench would help
avoid the pain of these problems. Bugs of opposite sign seldom cancel. However,
a rational response to these messages would certainly improve the behavior of
the system, not to mention the host itself.

We have argued these points within the ICCB incessantly and have not yet come up
with a clearly optimal and architectable recommendation. The experiments with
the fuzzballs, both as gateways and hosts, have shown that at least
some mechanisms are not difficult to implement and work very well. Unfortunately,
the inertia against change, especially in the case of vendor-maintained software,
is terrific.

Dave
-------
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Feb 84 17:18:33 cst
From:      jsq@ut-sally.ARPA (John Quarterman)
To:        Mike.Accetta@cmu-cs-ius.ARPA
Cc:        <WWB.TYM@office-2.ARPA>, Barns@ut-sally.ARPA, Bill@ut-sally.ARPA, jsq@ut-sally.ARPA, mills@dcn6.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Re: A short story and Martian Attack on OFFICE-8
I'd already notified the appropriate people at ut-ngp (UT Computation Center)
before your letter.  [97.128.13.75] is ut-ngp's local ethernet address
(about time to get a real network number, I'd say), but [97.128.13.72]
doesn't seem to correspond to anything (at least on this planet...).
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Tue,  7 Feb 84 17:35:40 CST
From:      Bill Lee <lee@ut-ngp.ARPA>
To:        Mike.Accetta@cmu-cs-ius.ARPA, WWB.TYM@office-2.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: A short story and Martian Attack on OFFICE-8
Ok, we are still alive and looking for the Martians. They seem to be us.
In any case, this problem should go away very shortly. We seem to be
letting some Ethernet traffic out on the ARPANET in an attempt to find
a gateway that knows how to route things. This is especially unfortunate
since these packets are coming from an unknown host on an unknown network
(at least to the rest of the ARPANET). We will try very hard to prevent
this from happening again.
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 7 February 1984 16:42:39 EST
From:      Mike.Accetta@cmu-cs-ius
To:        mills@dcn6, Bill Barns <WWB.TYM@office-2>
Cc:        tcp-ip@sri-nic
Subject:   Re: A short story and Martian Attack on OFFICE-8
After some investigation, the Martian attack seems to be originating
from host 0 on IMP 62 (UT-NGP).  At the moment, CMU-GATEWAY is
receiving frequent packets from this IMP port with an IP source address
of 97.128.13.72 (somewhere on Mars) and an IP destination address of
128.2.254.132 (CMU-CS-G).

CMU-CS-G responds to the connection attempts and routes its replies
back to CMU-GATEWAY.  CMU-GATEWAY (itself having no direct
communication with Mars) then asks a few of its gateway neighbors
(including DCN-GATEWAY) if they know they way, yielding the previously
described results.

Of course, the question of the moment is now: have the Martians left
anyone alive in Texas to fight back?

			- Mike
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      08-Feb-84 02:21:26-UT
From:      mills@dcn6
To:        tcp-ip@nic
Subject:   Martian chronicles
Folks,

The Martians have just landed at the dcn6 spaceport (25, or smtp, that
is). Kamikazegrams are falling every fifteen minutes from 97.128.13.75
spewing unreachable shrapnel all about. The Protocol Police have been
roused and horsed, but their numbers are sadly divided while fighting Smany
battles under alien Suns. Will the last datagram, source-quenched from our zoo,
please turn off the lights?

Sadly, I bury our frazzled fuzzballs and resolve to go forth and beat those
aliens caught in their Ethernets around their ears with a Valid Network Number.

Long live the Czar!

Dave
-------
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1984 1420 PST
From:      Eric P. Scott <EPS@JPL-VLSI>
To:        TCP-IP@SRI-NIC
Subject:   I see no Martians here
You don't see our "unadvertised" (and potentially conflicting)
network addresses courtesy of the Class A logical host chameleon.
UT-NGP, is that a viable solution for you?

					-=EPS=-
------
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Wed,  8 Feb 84 15:26:49 CST
From:      Paul Milazzo <milazzo@rice>
To:        Mike.Accetta@cmu-cs-ius
Cc:        mills@dcn6, Bill Barns <WWB.TYM@office-2>, tcp-ip@sri-nic
Subject:   Re: A short story and Martian Attack on OFFICE-8
A quick glance out the window reveals the Houston skyline still safely
in place.  Still, Rice periodically repulses a similar attack from the
Martians, and I believe I understand the cause.

Net 97 is what certain 4.2bsd sites which do not employ ARP use to
address Interlan Ethernet boards.  The Ethernet interface replaces the
"97" with the high 3 bytes of an Interlan Ethernet address (02-07-01),
and the remaining 3 class A address bytes become the lower 3 bytes.
Thus, [97.128.13.72] corresponds to an Ethernet address of
02-07-01-80-0D-48.  This is either the Ethernet board in UT-NGP or a
host on UT's local network for which UT-NGP is gatewaying packets.

				Paul G. Milazzo <milazzo@rice>
				Dept. of Mathematical Sciences
				Rice University, Houston, TX
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1984 at 0827-PST
From:      bobbi@sri-tsc
To:        TCP-IP@Sri-Nic
Cc:        bobbi@sri-tsc, dan@sri-tsc
Subject:   gateways

	I've been tasked with determining the availability of
a "compact, single-purpose processor" that could be a gateway
between an Ethernet LAN and a packet-switching network.  The
gateway should support the Ethernet, TCP/IP, and Address
Resolution protocols on one side and IP and 1822 protocols on
the other.

	I would appreciate any suggestions of vendors and/or
contacts who could supply me with product information on
gateway hardware and software.  Thank you for your help.

				-Bobbi
				 bobbi@sri-tsc
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1984 10:57:50 PST
From:      MILLS@USC-ISID
To:        bobbi@SRI-TSC, TCP-IP@SRI-NIC
Cc:        dan@SRI-TSC, MILLS@USC-ISID
Subject:   Re: gateways
In response to the message sent   9 Feb 1984 at 0827-PST from bobbi@sri-tsc

Bobbi,

We use LSI-11 "fuzzballs" for general packet-switching jobs in our
shop. They support IP, 1822, HDH, GGP, EGP and 17 different hardware
devices, including Interlan and 3COM Ethernets, as well as several
kinds of SRI and ACC ARPANET gizmos. We happen to use then with
various kinds of disks, since we tend to load miscellaneous application-
level stuff into them. Others, including Paal Spilling at NTARE, are
using them in the diskless configuration for the same application
as you describe.

If you need further informationk please see the file DCNET.DOC in the
MILLS directory at ISID. You should contact me directly for further
correspondence, rather than copy everybody in this group.

Dave
-------
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Feb 84 10:45:10 cst
From:      jsq@ut-sally.ARPA (John Quarterman)
To:        tcp-ip@sri-nic.ARPA
Cc:        clyde@ut-ngp.ARPA, jsq@ut-sally.ARPA, lee@ut-ngp.ARPA, smoot@ut-sally.ARPA
Subject:   Martians Beaten Back / Networks Sigh in Common Relief
Checking the backlog of TCP-IP list messages, I see nobody else has
announced the problem has been fixed, and there seems to still be interest,
so here's an announcement:

	From jsq Thu Feb  9 10:29:42 1984
	Date: Thu, 9 Feb 84 10:28:53 cst
	From: jsq (John Quarterman)
	Posted-Date: Thu, 9 Feb 84 10:28:53 cst
	Received-Date: Thu, 9 Feb 84 10:28:53 cst
	Message-Id: <8402091628.AA12662@ut-sally.ARPA>
	Received: by ut-sally.ARPA (4.22/4.22)
		id AA12662; Thu, 9 Feb 84 10:28:53 cst
	To: brescia@BBN-UNIX
	Subject: Re:  Have you been getting these mail exchanges?
	Cc: clyde@ut-ngp, jsq, smoot
	
	Yes.  I threw in my two bits on the TCP-IP list a couple of times.
	
	It seems the folks at ut-ngp configured their Interlan board before
	their ACC IMP in their 4.2BSD kernel configuration file.  The effects
	of this are actually documented in "Installing and Operating 4.2BSD,"
	but it's easy to overlook that paragraph....  Anyway, the wormhole
	the Martians came through has evidently been closed.
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Feb 84 12:51:25 EST
From:      Jonathan Dreyer <jdreyer@BBN-UNIX>
To:        bobbi@sri-tsc
Cc:        TCP-IP@Sri-Nic, dan@sri-tsc
Subject:   Re: gateways
The BBN gateways currently support both Ethernet with ARP and 1822,
and we have a few operational gateways with both an Ether leg and an
1822 leg.  The gateway runs on LSI-11s with Interlan Ethernet boards
and ACC 1822 boards.

These are IP gateways; any encapsulated TCP information is passed
transparently.

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      10 February 1984 10:43 est
From:      Ata.SysMaint at RADC-MULTICS
To:        Mark Crispin <MRC at SU-SCORE>
Cc:        TCP-IP at SRI-NIC, Ata.SysMaint at RADC-MULTICS
Subject:   Re: FTP implementation questions
    Date:  Fri 27 Jan 84 20:44:00-PST
    From:  Mark Crispin <MRC@SU-SCORE.ARPA>
    Subject:  FTP implementation questions

         I have the following questions for the Internet community regarding
    FTP.  Instead of hearing a chorus of "no"s I would rather just hear from
    those who can answer "yes" to any or all of the following questions:

Answers are for the Multics FTP server.

    . Does your FTP implementation implement TYPE L with bytesizes OTHER than
      8, 32, or 36?  If so, is it useful or necessary to transfer with such a
      bytesize?

Yes, we support a logical bytesize of 9 only with the type L.  This is
to support the native bytesize of 9. Processing is like type I. Where
one would use TYPE L 9 instead of type I (to the Multics FTP server) is
hypothetically  possible, but doubtful in reality.

    . Would you consider as deficient an FTP implementation which did not
      support a TYPE L bytesize other than 8, 32, or 36?  Would a useful data
      transfer be prevented by this deficiency?  Give examples.

I would think that most machines would support a logical bytesize based
on their hardware's native bytesize regardless of whether it is 8,32, or
36.

    . The current FTP standard does not define the 0xx FTP reply codes the way
      the previous one did.  Do you feel that an FTP server should be prevented
      from issuing any unsolicited or "irrelevant" replies, or that it is
      alright to continue to use a 0xx FTP reply code?  What will your FTP user
      software do when it encounters a 0xx reply code (I feel that the "right
      thing" is to ignore it, optionally printing it on the user's terminal).

In my opinion, FTP reply codes of the 0xx flavor are illegal and should
never be sent.  All system messages (unsolicited) should be sent without
reply codes as per RFC 765 page 33. However on some systems (Multics is
one culprit, I admit) these spontaneous messages are buried whithin the
operating system code with the old 0xx reply format and are hard to
dispose of. Therfore, it is not unreasonable for a user FTP to print the
message on the user terminal, otherwise ignoring it.

    . Consider an FTP implementation where the REIN command is not implemented
      and you cannot change your USER once you have logged in.  Suppose this
      implementation allows an unlogged-in RETR by doing an implicit login of
      ANONYMOUS (the special account which allows retrieval of public-access
      files).  Should the FTP implementation announce the auto-login?  If 0xx
      codes are allowed, 030 is the obvious code.  If 0xx is not allowed, what
      would you consider valid for it to use to announce the auto-login
      (remember, this will prevent a login as something else).

If the auto-login anouncemnet is unsolicited, then no reply code should
precede it.

    . Does your FTP user process change the port after each data transfer in
      Stream mode?

Yes, otherwise you may be prevented from doing further file transfers
for a while. This is caused by some data connections taking over a
minute to fully close.

    . Does your FTP user process implement a mode other than Stream mode?  If
      so, which?

Yes, we implement block mode also.  The latest version should work
properly.
    -------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Sat 11 Feb 84 12:31:28-PST
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        Mills@DCN6.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Another nastygram report
As of sometime in the evening of 8 February, SU-SCORE has *all* the
BBN/ISI fixes for "runaway ACK" as passed to me.  Any instances of
runaway ACK after that time (let's say starting from 9 February) would
be a different bug.  I think we would all appreciate hearing if the
fixes at SU-SCORE so far have fixed the problem, because if they
haven't, further investigation by all parties is required.
-------
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 84 19:59:25 EST
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        Mills@DCN6.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Another nastygram report
I just looked at our INTERNET.GATEWAYS.  It does not list 128 8 or
128 4.  This suggests that some other gateway is telling us to use
DCN-GATEWAY.  Unfortunately we don't log ICMP level transactions,
so I am unable to tell what is going on.  However if Tops-20 does what
it is supposed to do, there aren't a lot of candidates.  The 
only gateways we list as PRIME are
  DCEC-MILNET-GW
  ARPA-MILNET-GW
  BBN-CRONUS-GW
These are our assigned primary and alternate Milnet gateway, and a
randomly chosen BBN-operated gateway.
-------
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      11-Feb-84 15:35:23-UT
From:      Mills@dcn6
To:        TCP-IP@nic
Subject:   Another nastygram report
Folks,

The Nastygram Novellas continue. Today's hit list includes:

10.0.0.15	ROCHESTER
10.0.0.51	SRI-NIC	
10.0.0.89	COLUMBIA-20
10.1.0.31	CCA-VMS
10.1.0.72	BBN-UNIX
10.2.0.14	CMU-GATEWAY
10.2.0.52	USC-ISIF
10.2.0.56	AIDS-UNIX
10.2.0.58	RUTGERS
10.2.0.77	MIT-MC
10.2.0.82	BBN-INOC
10.3.0.11	SU-SCORE
10.3.0.44	MIT-MC
10.3.0.63	BBN-TEST3
10.4.0.2	SRI-AI
10.5.0.2	SRI-IU
128.32.0.11	UCBKIM
14.0.0.12	RICE
18.26.0.37	MIT smallfry

The following data were collected in the DCN-GATEWAY log over the two-day
period from about 20:00:00 Feb 8 to 20:0:0 Feb 10. This time I sorted the log
by host, so that I could call out the problems more easily. Note that this
scrambles the time relationships, so that you can't easily tell the times of
the events during the ... duplicate(s) ... periods.

Remember, ICMP 003 is destination-unreachable, ICMP 004 is source-quench and
ICMP 005 is redirect. The addresses refer to those in the original datagram,
not the ICMP itself, which is sent to the first address.

During this period the BBN test EGP gateway appeared brain-damaged, so I
reactivated our GGP and peered with MILARP. Thus, one would expect spasms as
the GGP system counted to infinity when some net or gateway died. During such
spasms one would also expect redirects to flail about, probably accounting for
some of the mischief recorded below. The annotated script follows.

10.0.0.15	ROCHESTER
This guy may have old gateway tables. Net 128.8 (UMDNET) is reachable now only
via a dumb gateway on MILNET, but used to be reached via DCN-GATEWAY.
00:41:13 006 ?TRAP-I-ICMP 005 000 [10.0.0.15] -> [128.8.0.4]

10.0.0.51	SRI-NIC	
Only one source-quench returned to this guy, so probably not significant.
23:00:41 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1]

10.0.0.89	COLUMBIA-20
Multiple offenses. Evidence of runaway-ACK in the first spasm, old gateway
tables for net 128.8 in the rest.
00:52:01 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
	... 67 duplicate(s) ...
23:25:31 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
16:54:05 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.11]
00:55:00 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
	... 71 duplicate(s) ...
23:59:14 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
00:15:07 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]
	... 61 duplicate(s) ...
19:05:41 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]
19:15:30 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4]
	... 2 duplicate(s) ...
19:15:39 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4]
19:15:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]
	... 16 duplicate(s) ...
23:42:29 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]

10.1.0.31	CCA-VMS
(Is this guy running Access-T?) Possible old tables for 128.8.
02:53:41 006 ?TRAP-I-ICMP 005 000 [10.1.0.31] -> [128.8.0.8]

10.1.0.72	BBN-UNIX
Another 128.8 problem. This is a known good player, which leads me to believe
this particular microspasm may have been the result of a counting-to-infinity
glitch.
22:55:49 006 ?TRAP-I-ICMP 005 000 [10.1.0.72] -> [128.8.0.4]
22:55:50 006 ?TRAP-I-ICMP 005 000 [10.1.0.72] -> [128.8.0.4]

10.2.0.14	CMU-GATEWAY
Note the kamikazegrams to nets 0, 77 and 97, some of them persistent. The
Martians have apparently not been blown away yet. The remainder suggest
trouble with redirects during counting-to-infinity spasms. Note, this gateway
is ALWAYS-UP according to the NIC tables.
02:20:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [0.0.0.0]
16:22:57 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [0.0.0.0]
22:06:06 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.31.41.120]
	... 4 duplicate(s) ...
22:09:22 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.31.41.120]
14:37:03 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.34.251.1]
04:31:58 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [14.0.0.12]
21:46:43 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.15.5]
22:02:04 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.15.5]
04:23:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.21.6]
	... 3 duplicate(s) ...
22:16:26 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.21.6]
17:41:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.36.5]
20:00:09 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [26.0.0.14]
05:41:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [26.1.0.34]
00:15:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5]
	... 18 duplicate(s) ...
22:51:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5]
00:33:57 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5]
	... 20 duplicate(s) ...
23:35:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5]
05:21:53 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [36.40.0.205]
16:20:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [36.40.0.205]
22:25:36 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [77.45.0.2]
22:05:26 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [8.0.0.7]
00:06:33 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]
	... 122 duplicate(s) ...
23:58:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75]

10.2.0.52	USC-ISIF
Known good player apparently mildly annoyed by network glitches. Not believed
significant.
21:19:08 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.47]
	... 7 duplicate(s) ...
21:24:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.47]
21:15:31 006 ?TRAP-I-ICMP 005 000 [10.2.0.52] -> [128.9.0.48]
	... 18 duplicate(s) ...
21:15:34 006 ?TRAP-I-ICMP 005 000 [10.2.0.52] -> [128.9.0.48]
21:17:31 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.48]
	... 5 duplicate(s) ...
21:27:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.48]

10.2.0.56	AIDS-UNIX
Old tables?
01:46:25 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4]
	... 8 duplicate(s) ...
23:11:17 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4]

10.2.0.58	RUTGERS
Fuzzy 128.4.0.2 has been hiding for some time now. Maybe somebody here tried
to pet it. Also, suspected old 128.8 tables.
06:03:03 006 ?TRAP-I-ICMP 003 001 [10.2.0.58] -> [128.4.0.2]
	... 3 duplicate(s) ...
06:03:20 006 ?TRAP-I-ICMP 003 001 [10.2.0.58] -> [128.4.0.2]
00:00:58 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
	... 48 duplicate(s) ...
18:53:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
19:13:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4]
	... 3 duplicate(s) ...
19:13:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4]
19:23:51 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]
	... 14 duplicate(s) ...
23:32:23 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4]

10.2.0.77	MIT-MC
Redirects probably resulting from spasm not believed significant.
20:40:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65]
	... 7 duplicate(s) ...
20:40:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65]

10.2.0.82	BBN-INOC
This is a very frisky host, as noted on previous occasions. Note the spasm
beginning about 20:16, indicating something big broke about then. That may
account for many of the redirects reported to other hosts. The data are
sorted the wrong way to correlate properly, however.
20:34:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.16.3.0]
	... 7 duplicate(s) ...
20:34:09 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.16.3.0]
08:54:29 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1]
	... 15 duplicate(s) ...
08:57:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1]
09:00:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1]
	... 2 duplicate(s) ...
09:06:30 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1]
20:16:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1]
	... 15 duplicate(s) ...
20:19:13 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1]
20:22:10 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1]
	... 2 duplicate(s) ...
20:28:18 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1]
21:15:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.9.0.81]
	... 32 duplicate(s) ...
21:15:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.9.0.81]
20:16:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.29.1]
	... 15 duplicate(s) ...
20:19:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.29.1]
20:22:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.29.1]
	... 2 duplicate(s) ...
20:28:18 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.29.1]
08:53:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4]
	... 40 duplicate(s) ...
20:19:13 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4]
20:22:10 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.46.4]
	... 2 duplicate(s) ...
20:28:18 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.46.4]
20:34:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [32.3.0.42]
	... 7 duplicate(s) ...
20:34:15 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [32.3.0.42]
20:33:06 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [35.7.0.0]
	... 7 duplicate(s) ...
20:33:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [35.7.0.0]

10.3.0.11	SU-SCORE
Classic indications of the runaway-ACK problem, probably at least two
occasions.
02:07:38 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]
	... 151 duplicate(s) ...
23:31:20 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1]

10.3.0.44	MIT-MC
Our backdoor customer on FORDNET probably went belly-up for a couple of
minutes. Not significant.
20:01:49 006 ?TRAP-I-ICMP 003 001 [10.3.0.44] -> [128.5.32.1]
	... 4 duplicate(s) ...
20:02:03 006 ?TRAP-I-ICMP 003 001 [10.3.0.44] -> [128.5.32.1]

10.3.0.63	BBN-TEST3
This is our EGP peer, which gets knocked with source-quench when some other
player, probably suffering from the runaway-ACK bug, hammers on DCN-GATEWAY.
The times suggest the bad guys are COLUMBIA-20 and SU-SCORE.
02:08:24 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17]
	... 11 duplicate(s) ...
23:20:24 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17]

10.4.0.2	SRI-AI
Old tables?
17:53:49 006 ?TRAP-I-ICMP 005 000 [10.4.0.2] -> [128.8.0.4]
	... 2 duplicate(s) ...
19:03:25 006 ?TRAP-I-ICMP 005 000 [10.4.0.2] -> [128.8.0.4]

10.5.0.2	SRI-IU
Old tables?
01:56:08 006 ?TRAP-I-ICMP 005 000 [10.5.0.2] -> [128.8.0.10]

128.32.0.11	UCBKIM
This would seem to be a runaway-ACK problem; however, this is a VAX, leading
me to suspect a retransmission-timeout problem (set way too short). My
intelligence reports this to be a known problem with the 4.2 distribution.
21:54:11 006 ?TRAP-I-ICMP 004 000 [128.32.0.11] -> [128.5.32.1]
	... 124 duplicate(s) ...
23:45:20 006 ?TRAP-I-ICMP 004 000 [128.32.0.11] -> [128.5.32.1]

14.0.0.12	RICE
Trying to pet a fuzzy too briskly. Probably not significant.
22:00:51 006 ?TRAP-I-ICMP 004 000 [14.0.0.12] -> [128.4.0.6]

18.26.0.37	MIT smallfry
IBM PC at MIT. These mutts are known to read the DCN-GATEWAY clock frequently.
This one probably got surprised by a source-quench in response to the UDP
request because somebody else was beating (runaway ACK?) on the gateway!
23:20:07 006 ?TRAP-I-ICMP 004 000 [18.26.0.37] -> [128.4.0.1]
23:20:09 006 ?TRAP-I-ICMP 004 000 [18.26.0.37] -> [128.4.0.1]

Lessons learned deptartment:

1. The runaway-ACK problem continues to spasmatize the gateway system. At
   least two TOPS-20 hosts, COLUMBIA-20 and SU-SCORE, appear to have this bug,
   which apparently has been identified and fixed by the ISI system staff.

2. There is some evidence that the 4.2 distribution may have (initial) TCP
   retransmission timeouts set way too low. We have found five seconds to be
   a reasonable compromise for use over almost any existing path (see RFC889).

3. Implementors should expect source-quench in just about any situation,
   even using low-rate datagram protocols like UDP and EGP, and even when the
   sender is not at fault. When using TCP, the appropriate behavior in the
   case of one-way transmissions when the receiver gets one of these in
   response to an ACK it sent is an interesting case (should it shrink the
   window?).

4. The dumb-gateway table inertia seems uncomfortably high. The rash of
   misrouted net-128.8 traffic above (and the relatively minor level of
   misrouted traffic for other nets) suggests problems with old or conflicting
   table information. Net 128.8 is one of the nets advertised by DCN-GATEWAY
   in the GATEWAY portion of the NIC tables as reachable via that gateway.
   However, at least for the present, net 128.8 is wired in the core system
   as reachable via a dumb gateway (MARYLAND) on MILNET. However, DCN-GATEWAY
   does not currently advertise itself as a path to that net, either in EGP
   or GGP. I suspect that some of the dumb gateways on ARPANET may have
   wired in the old path and are failing to utilize redirect information.
   I suspect this problem may be happening elsewhere in the system.

Dave
-------
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      12-Feb-84 02:03:17-UT
From:      mills@dcn6
To:        CharlesHedrick<HEDRICK@RUTGERS.ARPA>, Mills@DCN6.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: Another nastygram report


Charles,

Thanks for the info. The detective hunt continues.

Dave
-------
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      12-Feb-84 22:09:22-UT
From:      Mills@dcn6
To:        TCP-IP@nic
Subject:   Gateway system performance
Folks,

As long as I have been banging on gateway issues, you might be interested in a
capsule evaluation of how well the existing system works and how it has
improved over the last several months. Following is an extract of gateway
traffic information collected on a weekly basis by Eric Rosen of BBN.
..

Searching from Mon Jan 30 00:02:12 1984 until Sun Feb  5 23:59:59 1984 (EST)
A total of 19295 throughput messages were received from 30 gateways

GWY GWY         RCVD           RCVD     IP       % IP         DEST   % DST
NO. NAME        DGRAMS         BYTES    ERRORS  ERRORS       UNRCH   UNRCH
TOTALS      79,068,588 3,748,292,651    22,989   0.03%     329,104   0.42%

GWY GWY         SENT           SENT    DROPPED    % DROPPED
NO. NAME        DGRAMS         BYTES   DGRAMS        DGRAMS
TOTALS      80,874,600 3,977,797,017   485,184        0.60%

60.90% of all received packets are addressed to a gateway
62.61% of all sent packets originate at a gateway
57.56% of all sent packets are forwarded to another gateway

..

Last August I analyzed similar data on 19 gateways in order to determine the
protocol overhead and effectiveness of the system. The result was pretty
dismal, showing that, of the traffic transiting the gateway system, less than
one packet in five represented real user data and almost half the packets were
misrouted.

Following is a more detailed summary of these results. Note that all values
have been normalized on a per-gateway, per-hour packet basis. (I'll describe
the assumptions and methods for calculation separately if there is sufficient
interest.)

Totals - received 11591  sent 12406  difference 815 
Received addressed to a gateway   8345   to a host 3246 
Sent originating at a gateway     9304   at a host 3102 
Sent forwarded to another gateway 7567   to a host 4839 

Redirects sent to hosts     959 
GGP pings sent/received     6608 
Host pings sent/recieved    1737 
Host traffic received       2287 
Host traffic sent           2143 

Efficiency      .197
Misroutes       .419

Last week I analyzed the data shown at the beginning of this message and
obtained the following reults:

Totals - received 15674  sent 16051  difference 377 
Received addressed to a gateway   9545   to a host 6129 
Sent originating at a gateway     10047  at a host 6004 
Sent forwarded to another gateway 9245   to a host 6806 

Redirects sent to hosts     502 
GGP pings sent/received     8743 
Host pings sent/recieved    802 
Host traffic received       5627 
Host traffic sent           5502 

Efficiency      .359
Misroutes       .089

In spite of the growth from 19 to 30 gateways, more than one packet in three
is real user data and less than one packet in ten is misrouted. A casual
inspection of the data reveals three reasons for the improvement in
performance:

1. Host pinging has diminished.

2. Hosts are paying closer attention to redirects.

3. Host traffic has grown faster than GGP traffic.

The principal reason for the low efficiency is the overhead due to the
gateways pinging each other, which is hardly news to anybody. However, many
of the 30 GGP gateways now in the core system are used to splice relatively
low-traffic local nets to the ARPANET and could be converted to EGP without
significant loss of service. This would dramatically reduce the pinging din,
as well as reduce the impact of up/down spasms. We could even split the core
into two or more cliques of gateways, each running GGP between themselves and
connected to the others by EGP.

Since the deployment of "operational" EGP gateways is now being discussed, I
suggest an interesting experiment might be to set up and test this idea.
DCN-GATEWAY is in fact set up and instrumented to do this. The test would
involve merely configuring one or more existing GGP gateways to include only
each other and DCN-GATEWAY in their neighbor tables. DCN-GATEWAY would then
boogie with them using either GGP or EGP and with the rest of the world using
EGP and the core system. In principle, this idea would work with the
operational EGP gateways as well. If there is interest in such a test, please
contact me directly.

Dave
-------
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Mon 13 Feb 84 11:39:43-PST
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        Hornig%SCRC-QUABBIN@MIT-MC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, bug-ftpser@MIT-XX.ARPA, lispm-networks%SCRC-TENEX@MIT-MC.ARPA
Subject:   Re: TOPS-20 FTP server
If it makes anyone feel any better, I am finishing a rewrite of the
TOPS-20 FTP server which I am confident won't have this problem.
However, since it uses the DEC system call interface (the primary
reason for the rewrite), I fear the old FTP server won't go away for
a very long time.  It took Tenex TELNET several years to go away on
TOPS-20.
-------
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Feb 84 09:26 EST
From:      Charles Hornig <Hornig%SCRC-QUABBIN@MIT-MC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        bug-ftpser@MIT-XX.ARPA, lispm-networks%SCRC-TENEX@MIT-MC.ARPA
Subject:   TOPS-20 FTP server
I have run into a consistent problem talking to Internet TOPS-20 FTP
servers from hosts on our local network.  All of the ones I've tried
(SRI-NIC, MIT-XX, ISIE, ECLB) do not respond to "USER ANONYMOUS" when
the machine connecting is NOT in the NIC host table.  When it is in the
host table, everything works fine.  In particular, it happened this
morning connecting to SRI-NIC from SCRC-MERRIMACK (192.10.41.80) but not
from SCRC-RIVERSIDE (192.10.41.21).  Does anyone have any ideas on how
to deal with this?  Do I have to put all of our hosts in the NIC table?
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Feb 84 10:32:36 PST
From:      Andy Sills <sills@AEROSPACE>
To:        TCP-IP@SRI-NIC, TCP-IP@BRL
Cc:        perillo@SRI-NIC
Subject:   TCP/IP Implementation for RSX-11/M
TWIMC:

	I would like to know how many users running RSX-11/M would be
interested in getting a TCP/IP implementation for their machines? The
key to doing this is a board that plugs into the Unibus and creates a
virtual IBM PC running MS-DOS. The software and hardware associated with
this board create the connection between the virtual file structure of
RSX and the host file structure of the PC. Tasks started under this
program appear to be running on a PC even though they are under RSX.

	Here's the trick. If there really were a PC, there would be
an Ethernet board plugged into the mother board, and TCP/IP code
that already exists and would talk to that board. In an RSX machine,
there would be an Ethernet board for networking, AND this virtual
PC emulator board. What remains to be done is to write the code for
having the virtual PC talk to the RSX machine's Ethernet board as if
that board were actually mounted in a real PC.

	This job can be done as a special project (very expensive)
or as a developed product by a comnpany that is willing to try. They
would like to assess the interest of the RSX community. Aerospace
has two users interested. Are there any others? Please reply to 
sills@AEROSPACE if you are. 
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1984 13:44:16 PST
From:      MILLS@USC-ISID
To:        sills@AEROSPACE, TCP-IP@SRI-NIC, TCP-IP@BRL
Cc:        perillo@SRI-NIC, MILLS@USC-ISID
Subject:   Re: TCP/IP Implementation for RSX-11/M
In response to the message sent            Tue, 14 Feb 84 10:32:36 PST from sills@AEROSPACE

Folks,

While this appears to be an exotic and wonderful can of worms, there is
at least one alternative. COMSAT is distributing IP/TCP code that runs
under RSX to support the international INTELPOST electronic-mail network.
The code happens to be a spinoff of the infamous Fuzzball code used here
for Internet research for some years. Further information from Dave Jupin at
COMSAT Laboratories (301) 428-4571.

Dave
-------
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1984 14:00-PST
From:      BILLW@SRI-KL
To:        sills@AEROSPACE
Cc:        TCP-IP@SRI-NIC, TCP-IP@BRL, perillo@SRI-NIC
Subject:   Re:        TCP/IP Implementation for RSX-11/M
Well, there is a company ("ExceLAN", San Jose), who manufatcures
an ethernet board with an onboard 8088 processor and TCP/IP
software.  All I have around is a blurb on their multibus board,
But I think they also have a unibus version.  I dont know anything
else about the product: their phone number is 408 945-9526
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1984 11:50-EST
From:      CLYNN@BBNA
To:        Hornig%SCRC-QUABBIN@MIT-MC
Cc:        tcp-ip@SRI-NIC, bug-ftpser@MIT-XX lispm-networks%SCRC-TENEX@MIT-MC
Subject:   Re: TOPS-20 FTP server
I tried to repeat your problem by logging into SRI-NIC, MIT-XX, and
ISIE from one of the BBN terminal concentrators (which are not
listed in the NIC's host tables).  They all accepted the USER
ANONYMOUS, PASS ... sequence.  What are we doing differently?
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Feb 84 1:43:35 EST
From:      Ron Natalie <ron@brl-vgr>
To:        Andy Sills <sills@aerospace>
Cc:        TCP-IP@sri-nic, TCP-IP@brl, perillo@sri-nic
Subject:   Re:  TCP/IP Implementation for RSX-11/M
Putting TCP/IP on RSX-11M is a good idea.  Your suggestion on how to
do it is a little bazaar.  IBM-PC's are hardly an effective network
interface.  If you've already got an ethernet or IMP interface for your
Machine, why not just implement the TCP/IP directly on the PDP-11
(this is practical if you are using one of the larger 11's eg. 44,45,55,70).

Try contacting my former employer, Martin Marritta.  They seem to have
FTP and TELNET at least on their RSX machines (MARTIN and MARTIN-ED).
Also a few other hosts including NRL-ARCTAN and NSWC-DL claim to be
up with TCP on RSX.  These are 11/40's.  All the RSX signons I've seen
say "SAMNET" if that's any help.

-Ron
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Feb 84 1:46:27 EST
From:      Ron Natalie <ron@brl-vgr>
To:        BILLW@sri-kl
Cc:        sills@aerospace, TCP-IP@sri-nic, TCP-IP@brl, perillo@sri-nic
Subject:   Re:  TCP/IP Implementation for RSX-11/M
The EXCELAN people seem to have a very nice implementation of TCP
on their board.  Unfortunately we are still waiting for the UNIBUS
board to be announced although they claim it is in the work.  We
are looking forward to using the EXCELAN's on our smaller machines
(23's and 34's).  It's got a really nice interface.

-Ron
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      15-Feb-84 03:06:46-UT
From:      Mills@dcn6
To:        TCP-IP@nic
Subject:   The babble diminishes
Folks,

Digging in the muck is paying off - the trash heap continues to diminish.
After discussions with individual implementors and fixes kindly supplied by
ISI and BBN, the primary law-benders mentioned in my previous messages have
been fixed. Like smallpox, the excitement now is to try to kill all the
beasties off. The following hosts are suspected of some traffic violations
still, although the wholesale destruction which prompted my recent messages
has tapered off a lot.

SRI-NIC: suspect runaway-ACK

15:59:23 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.32.1]
	... 44 duplicate(s) ...
16:24:53 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.32.1]
00:56:07 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1]
00:56:08 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1]

COLUMBIA-20: excessive source quench

01:55:25 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]
	... 4 duplicate(s) ...
19:01:23 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1]

COLUMBIA-20: excessive redirects for net 128.8

00:13:28 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
	... 50 duplicate(s) ...
23:43:27 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2]
00:01:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]
	... 45 duplicate(s) ...
23:03:21 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4]

CMU-GATEWAY: excessive misroutes

14:25:39 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.42.1.1]
00:06:19 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.42.1.6]
	... 2 duplicate(s) ...
21:25:03 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.42.1.6]
18:31:49 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.7.0.1]
00:13:30 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [14.0.0.12]
16:50:48 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [192.5.19.1]
16:51:01 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.21.4]
16:49:13 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [26.7.0.50]
01:28:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5]
	... 7 duplicate(s) ...
19:30:24 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5]

CMU-GATEWAY: Martian attacks

17:21:52 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [1.128.2.251]
15:41:46 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [19.0.0.0]
16:09:15 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.11.194]
	... 2 duplicate(s) ...
16:17:19 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.11.194]

The log scanned is for something over two days and has been culled to remove
the occasional redirect or unreachable for J. Random Host. If this is evidence
for similar behavior throughout the gateway system, things may be in much
better shape than I first feared. Unless the situation deteriorates I will
shut my mouth in this forum and go beat up the individual hosts directly.

Charlie Lynn's recent fix for the TOPS-20 "window whapper," in which arriving
TCP segments overrun the receiver window, almost exhausts my encrustated
punch list of outstanding performance-related issues. The list still contains
apparent connection-close problems noted at MIT-MULTICS, as well as known
TOPS-20 FTP server connection-close problems and suspected 4.2 initial
TCP timeout problems.

Dave
-------
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Feb 84 14:01 EST
From:      "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   martians indeed
Who will fix the "runaway duplicate long mail bug?} "
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Feb 84 15:54 EST
From:      Charles Hornig <Hornig%SCRC-QUABBIN@MIT-MC.ARPA>
To:        CLYNN@BBNA.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, bug-ftpser@MIT-XX.ARPA, lispm-networks%SCRC-TENEX@MIT-MC.ARPA
Subject:   Re: TOPS-20 FTP server
    Date: 14 Feb 1984 11:50-EST
    From: CLYNN@BBNA

    I tried to repeat your problem by logging into SRI-NIC, MIT-XX, and
    ISIE from one of the BBN terminal concentrators (which are not
    listed in the NIC's host tables).  They all accepted the USER
    ANONYMOUS, PASS ... sequence.  What are we doing differently?

We have found the problem.  It is our fault.  One of our gateways had a
very obscure bug involving Ethernet packets of length 3 mod 4.  The
TOPS-20 response for our hosts which weren't in the table was long
enough to set it off.  Sorry to bother you all.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      16-Feb-84 17:23:33-UT
From:      Mills@DCN6
To:        TCP-IP@SRI-NIC
Cc:        Byard@DCA-EMS, CAK@PURDUE, Clausen@USC-ISID, Fuzzball@USC-ISID, Gross@DCN7, Jay@FORD1, Louie@CVL, Mike.Accetta@CMU-CS-IUS, Mike@UMD9, Milazzo@RICE, Patrick@FORD-WDL1, Spilling@NTARE1
Subject:   Fuzzball throughputs
Folks,

You may be interested in the following overall performance data on the
fuzzball implementation. The data reveal the total processing times for
ordinary user interaction using a local terminal and for various network
processing functions. These particular data were collected on an LSI-11/23
system using 256 Kbytes of memory, a 30-Mbyte Winchester disk and Interlan
Ethernet interface.

The processing times were determined from a number of statistical counters and
timers maintained by the system itself and, in the case of interrupt times, by
outboard electronic instrumentation. The worst-case interrupt CPU time was
measured for the Winchester disk controller as about 800 microseconds - the
times shown below for other devices were based on prior measurements corrected
for the actual configuration.

Per-process times are obtained by counting the number of 60-Hz timer
interrupts when the process is active. Thus, if an interrupt occurs while the
process is active and does not result in a context switch, the interrupt time
is charged to the process. Also note that most processes are rescheduled
withing only a few milliseconds, so that this method is accurate only if (a)
the rescheduling event is not correlated with the timer event and (b) a large
number of events are averaged.

Fuzzballs are built using a pair of link-level processes which does the
internal packet switching for each network interface, a network-level process
which does the kernel-space IP and TCP processing, and an application process
for every local user or network server. A pair of terminal processes is
associated with each local terminal in the system. All except the application
processes are run in kernel space. Each application (user) process is run in a
separate user space as an emulated RT-11 background job.

Local terminal input/output times were measured by simply banging on a key and
watching the counters. Most of the processing in the user process is due to
RT-11 EMT emulation. For output-only this process burns only about 1100
microseconds per character. Note that character input is necessarily
character-at-a-time; however, character output is buffered several characters
per interprocess message.

The link-level process input/output times were measured using an ACC 1822
(DMA) interface connected to an ARPANET IMP. About two-thirds of the output
time is burned in the ARPANET 1822 leader code, which can result in a table
search to find gateway addresses.

The network-level process handles all datagrams landing at the host. The times
include reassembly queue processing, header validation, connection matching
and protocol module processing. For raw datagrams the protocol processing is
minimal, since the datagram is simply mapped into the appropriate user process
virtual space. For TCP datagrams the processing includes reassembly,
retransmission and copying to and from user virtual space. In both cases the
times include a mixture of short and long packets up to 576 octets.

Following is a summary of the data:

Terminal input/output (per character) DLV11 PI interfaces
Input interrupt			 500 est
Terminal input process		2429
Output interrupt		 300 est
Terminal output process		 816
User process			3893
				----
	Total			7938 microseconds/character

Link input/output (per packet) ARPANET 1822 DMA interfaces
Link input interrupt		 300 (est)
ARPANET net input process	2167
Link output interrupt		 300 (est)
ARPANET net output process	1876
				----
	Total			4643 microseconds/packet

Network process (per packet)
Raw datagrams			3280
TCP datagrams (segments)       13620

One way of looking at these figures is that the LSI-11/23 becomes CPU bound at
an aggregate data rate of 125 characters per second or 200 packets per second
(assuming the characters and packets pass right through the system). The
maximum aggregate character input rate is 150 characters per second and the
maximum aggregate output rate is 400 characters per second.

For datagrams landing at the host, the maximum raw-datagram rate is 125
packets per second, assuming equal input and output rates, while the maximum
TCP rate is 50 576-octet packets per second, exclusive of user processing.
Finally, an FTP disk-to-disk between a pair of fuzzies on an Ethernet is
about 8000 characters per second.

Obviously, the fuzzball performance can be improved, especially in the user
process. The overhead for RT-11 emulation is severe, as is the requirement
for character-at-a-time input. Packet processing can be improved by hashing
the net table, which has lately grown to over 60 entries. TCP processing
can be improved in the area of buffer management (every implementation
can make that statement).

Hopefully, this information will be useful in evaluating the performance of
other implementations using LSI-11 or similar horsepower.

Dave
-------
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Feb 84 0:24:39 EST
From:      Ron Natalie <ron@brl-vgr>
To:        tcp-ip@sri-nic
Cc:        nic@sri-nic, rnj@brl-vgr
Subject:   TACNEWS
The "@n" doesn't seem to give the TAC-NEWS host.  Just says
destination host unreachable.  Telnet-ing to the TAC-NEWS
address (8.7.0.4) yields the host but the old tacnews and
anonymous/guest logins no longer work.

-Ron
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Feb 84 08:31:20 CST
From:      george@EGLIN-VAX
To:        tcp-ip@sri-nic
Cc:        george@afsc-hq
Subject:   RSX TCP/IP
In light of the recent RSX / TCP discussions I will add another
message to the Bulletin Board. My apologies to those who are
aware or could care less about the following: 

AIR FORCE SYSTEMS COMMAND has supported a project called SAMNET
which implemented ARPANET protocols ( TCP/IP, FTP, and TELNET)
on PDP11 RSX11M as a network front end to CDC (NOSBE) mainframes.
This software has been released to several DOD and other govt
agencies. Any request for this software should be placed through
 
	AFSC/ACDT
	ANDREWS AFB, Wash. D.C. 20334

	telephone (301) 981-3137  AV 858-3137

Any technical questions to

	Calvin George 	
	AD/KRESS
	EGLIN AFB, Florida 32548

	(904)882-2276 or AV 872-2276
	George at AFSC-HQ or George at Eglin-VAX

The SAMNET software package uses RSX11M V3.1. TCP/IP and 1822 is provided
as an RSX11M ACP. Network I/O drivers are avialable for DEC 1822 interfaces,
IMP11A and IMP11B. The ACC LHDH/11 could be supported with slight mods to
the IMP11A driver.
 
User and Server FTP and TELNET are available. NVT is supported via substantial
modifications to the RSX terminal driver. Hence, the problem of upgrading
to RSX 4.x. 
 
The TCP/IP package does not support full internet support, no fragmentation/
reassembly, and no gateway messages. In short, it only works to HOSTs on
the same network. 
 
The software package ( TCP/IP, TELNET, FTP, and PDP to CDC software) uses
approximately 96Kwords (16bit) of a 128Kword system. Individual TELNET and FTP 
tasks use shared code ( part of the 96K) plus additional memory for buffers
and non-reentrant code. Currently the I/O drivers do not support 22bit 
addressing ( 11/44 and 11/70 ). This should not be difficult to do.
z

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Feb 84 11:26:15 EST
From:      Andrew Malis <malis@BBN-UNIX>
To:        Ron Natalie <ron@brl-vgr>
Cc:        tcp-ip@sri-nic, nic@sri-nic, rnj@brl-vgr, malis@BBN-UNIX
Subject:   Re: TACNEWS
Ron,

The tac-news service has moved to SRI-NIC.  Typing "@n" opens
a connection to SRI-NIC, which then accepts the command (without
needing to log in) "tacnews".

Andy

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Mon 20 Feb 84 15:21:02-PST
From:      Jake Feinler <FEINLER@SRI-NIC>
To:        ron@BRL-VGR, tcp-ip@SRI-NIC
Cc:        nic@SRI-NIC, rnj@BRL-VGR
Subject:   Re: TACNEWS
Ron, et al,

The NIC machine was experiencing problems and was down at the time.
Also there was work being done on our IMPS.   Not sure which one
of these you hit.  Sorry for the inconvenience.

Jake
-------
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Feb 84 17:40 EST
From:      Schiller@MIT-MULTICS.ARPA (Jeffrey I. Schiller)
To:        mills@DCN6.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, jbn@FORD-WDL1.ARPA
Subject:   Re: SRI-NIC tinygram fever
We have been experiencing the same problem with SRI-NIC here at
MIT-MULTICS.  The problem here is that the large number of
retransmissions causes the our IMP to clog and malfunction (we are
connected via message mode HDH which has problems handling large amounts
of traffic).

We have been forced to use FTP to get our host table updates.

                    -Jeff
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      20-Feb-84 17:24:44-UT
From:      mills@dcn6
To:        tcp-ip@nic
Cc:        jbn@facc
Subject:   SRI-NIC tinygram fever
Folks,

Acting on a tip from John Nagle of Ford Aerospace, I traced the TCP segments
sent by SRI-NIC in response to a connection request to the host-name server
(port 101) and sending the ALL command. Presto, the reason for the alleged
fire-hose behavior on the part of SRI-NIC has been explained.

Remember, SRI swears on a stack that the runaway-ACK problem has been
f*i*x*e*d; however, an uncomfortably high incidence of buffer congestion and
resulting source-quench continue to be observed. From the trace, excerpted
below, it is apparent the host-name server packetizes in rather small 64-octet
segments and assumes an unrealistically small value for its retransmission
timer.

Following is an excerpt from the log of DCN6, which is connected via 4.8-Kbps
line to the DCN-GATEWAY, itself connected to the Mitre IMP via 56-Kbps line.
The Stamp column shows the arrival timestamp (milliseconds), IP Seq the IP
sequence number, LWE the position relative to the current RCV.NXT, Size the
size (octets) and Window the receive window after the segment has been stored.
A minus sign in the LWE column indicates an old (duplicate) segment, while a
minus sign in the Size column indicates the PUSH bit is set.

Time (UT)			Stamp	IP seq	LWE	Size	Window
----------------------------------------------------------------------
16:45:37 002 ?TRAP-I-TCP rcv	44044	53164	-384	-62	450
16:45:37 002 ?TRAP-I-TCP rcv	44327	53173	0	-62	388
16:45:37 002 ?TRAP-I-TCP rcv	44644	53165	-384	-64	450
16:45:38 002 ?TRAP-I-TCP rcv	44994	53174	0	-64	386
16:45:38 002 ?TRAP-I-TCP rcv	45178	53175	0	2	448
16:45:38 002 ?TRAP-I-TCP rcv	45428	53166	-386	2	450
16:45:38 002 ?TRAP-I-TCP rcv	45778	53167	-384	-62	450
16:45:39 002 ?TRAP-I-TCP rcv	46078	53176	0	-62	388
16:45:39 002 ?TRAP-I-TCP rcv	46378	53168	-384	-64	450
16:45:39 002 ?TRAP-I-TCP rcv	46728	53177	0	-64	386
16:45:40 002 ?TRAP-I-TCP rcv	46928	53178	0	2	448
16:45:40 002 ?TRAP-I-TCP rcv	47228	53169	-386	2	450
16:45:40 002 ?TRAP-I-TCP rcv	47578	53170	-384	-62	450
16:45:41 002 ?TRAP-I-TCP rcv	47911	53179	0	-62	388
16:45:41 002 ?TRAP-I-TCP rcv	48245	53171	-384	-64	450
16:45:41 002 ?TRAP-I-TCP rcv	48578	53180	0	-64	386
16:45:42 002 ?TRAP-I-TCP rcv	48778	53181	0	2	448
16:45:42 002 ?TRAP-I-TCP rcv	49011	53172	-386	2	450

Note that half of the arriving segments are duplicates, indicating NIC is
shooting itself in the foot with an unrealistically small value for its
retransmission timer. Second, almost all segments have the PUSH bit set, which
seems not a particularily good idea for this type of bulk data transfer, since
the receiver cannot safely aggregate ACKs.

The real problem is the use of rather small segments (tinygrams), which clog
up gateway buffers when hosts advertise reasonably large windows. John and I
have observed the results many times when one of his hosts attempts to update
its host tables this way and DCN-GATEWAY instantly contracts a case of
bufferitis. I suspect this contagion infects the ARPANET/MILNET gateways as
well.

The disease is not terminal, however, and can be treated by (a) using FTP, (b)
fixing the host-name server packetizer to favor larger segments. I suspect the
design choice of small segments here may be due to antibodies made after
infection by the "window-smasher" bug which gave us all the "individually
pushed 50-octet" fever.

Dave
-------
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      21-Feb-84 00:19:14-UT
From:      mills@dcn6
To:        mills@dcn6, tcp-ip@nic, jbn@facc
Subject:   Re: SRI-NIC tinygram fever


Folks,

The ink was hardly dry on my message when Ken Herrenstien fixed the NIC host-name
server to favor larger packets. Now it packs about 200 octets per segment and
no duplicates at all are observed. Good show!

I bet if the PUSH were removed from those segments, TOPS-20 TCP would pack up
to 576 octets in those 'grams like in the case of FTP. It looks from the slightly
unstable segment sizes that the packetizer is still quite delay sensitive. I
have seen this before in the case of NIFTP, which was changed to avoid the PUSH
with the result that the segments were positively stuffed.

Gee, the TOPSes are pretty well tamed just now. Maybe it's time to go beat up
the VAXen.

Dave
-------
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1984 0157 PST
From:      Eric P. Scott <EPS@JPL-VLSI>
To:        TCP-IP@SRI-NIC
Subject:   Please don't laugh...
I'm interested in any information regarding TCP/IP software and
LAN interfaces for Data General MV/series processors running
AOS/VS.  Failing that, I'll settle for any good free/public
domain TCP/IP implementations written in a transportable language
(C, PL/1).  BTW, these are 32-bit machines with lots of memory.

					-=EPS=-
------
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1984 16:37:02 EST (Thursday)
From:      John Swanson <jswanson@mitre>
To:        tcp-ip@sri-nic
Cc:        jswanson@mitre
Subject:   Commercially available Unix
	I am trying to compile a list of commercially supported UNIX
systems for VAX hardware. The limiting factor would be that they have TCP/IP 
and an IMP interface.  Anyone that can give me pointers please send
them to jswanson@mitre.  
		
		Thanks
			John Swanson

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1984 0542 PST
From:      Eric P. Scott <EPS@JPL-VLSI>
To:        TCP-IP@SRI-NIC
Subject:   A "Not Yet" on Data General
Date: 23-Feb-84 06:26 PST
From: Bill Barns  <WWB.TYM@OFFICE-2>
Subject: Re: Please don't laugh...
To: EPS@JPL-VLSI
Message-ID: <[OFFICE-2]TYM-WWB-463J4>
In-reply-to: EXT-EPS-4637Z

If you refer to the Washington Post, Feb. 12 issue, page G15 (I'm sure you have 
this constantly by your side), you will observe a 1/6 page DG help-wanted ad 
looking for all kinds of software types.  There is a sentence "Projects in the 
following areas: [lots]..., ARPANET TCP/IP..."  The inference seems clear but I 
have no further information about it.

The same ad has probably run all over the country.  From the text of the ad I 
gather that the work is being done in Westboro, Mass.  If for some reason you 
actually want a copy of the ad, I could probably throw one in the US Snail to 
you... however I imagine that a help-wanted ad will be a poor substitute for an 
executable implementation...  -b
-------
Received: by NYU.ARPA; Thu, 23 Feb 84 11:02:51 est
Date: Thu, 23 Feb 84 11:02:51 est
From: salkind@nyu (Lou Salkind)
Message-Id: <8402231602.AA06150@NYU.ARPA>
To: EPS@JPL-VLSI
Subject: Re:  Please don't laugh...

Interlan sells an Ethernet board for AOS/VS.  I don't know of any
TCP/IP implementations, but it is rumored a group in North
Carolina is working on it.

I would be curious to hear what you find out.
-------
Date: Thu, 23 Feb 84 11:13 EST
From: Dennis Rockwell <drockwel@BBN-VAX>
Subject: Re: Please don't laugh...
To: Eric P. Scott <EPS@JPL-VLSI>

The BBN TCP/IP implementation is public domain (the Feds financed it),
is written in C, and is available without a UNIX license.  If you're
interested, send your USMail address to abreau@bbn-unix, and she'll
send you our license forms.
-------
Date: 23 Feb 1984 1225-PST
From: Chris <Pace@USC-ECLC.ARPA>
Subject: Re: Please don't laugh...
To: EPS@JPL-VLSI.ARPA
Phone:  (213) 743-5520
Office: PHE-220
In-Reply-To: Your message of 23-Feb-84 0157-PST


	Could you send me what ever responses that you get that
dont go back to the list (either to the list or me individually
is fine).  Thanks.

		Chris.
-------
Date: Thu 23 Feb 84 17:29:32-PST
From: Francine Perillo <PERILLO@SRI-NIC>
Subject: Re: TCP/IP for 32-bit DGC systems
To: EPS@JPL-VLSI
cc: PERILLO@SRI-NIC
In-Reply-To: Message from "Eric P. Scott <EPS@JPL-VLSI>" of Fri 17 Feb 84 11:28:00-PST

Hi Eric,

I spoke with a fellow from Data General in Westboro, MA earlier this
month and he claims that they are working on developing TCP/IP for
the AOS/VS operating system for the MV and Eclipses.  He said that
it would be a year before it would be available as a product.  He would
be glad to talk with you, as I asked him if I could send anyone his way.

	James Hirni
	Data General
	4400 Computer Drive
	Westboro, MA
	(617) 366-8911 ext. 6173

-Fran
------
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Feb 84 12:28:54 pst
From:      sun!rusty@phoenix (Russel Sandberg)
To:        tcp-ip@sri-nic.ARPA
Subject:   UNIX 4.2 FIN_WAIT_2 bug fix
Folks,

As the new babysitter of the Berkeley UNIX 4.2 TCP/IP
code here at Sun,  I was asked to look at the "hanging FIN_WAIT_2"
problem.  For those of you who haven't heard about this one it works
like this:  an established connection is closed by the process on the
receiving end during data transfer; the sender goes into LAST ACK
and tries to send out its data; meanwhile, the receiver has thrown
away its socket structure, which includes the receive buffers,
and in the process closed its receive window; the sender probes the
zero window which the receiver can't open; and both ends stay around
forever because of the probe-ack exchange.

The obvious solution is for the receiver to accept the data and drop it on
the floor, since there is no one to deliver it to.  This is hard.  It involves
faking the receive window, special casing data received on a fake window,
and in fact, in a sense it violates the protocol because it makes the sender
think its data got delivered intact.

My solution is to sent an RST when data is received on a connection for
which there is no process to deliver to.

The sending side should also be fixed because not all sites will have the
receive side fix installed.  The sender should not persist forever probing
a zero length window (at least when it is in LAST ACK state).

The changes to the UNIX kernel to implement these two fixes are minimal.
In fact, on the sending side, the code already exists but it is never executed.

Please let me know if you think this violates the TCP specification.

	Russel Sandberg
	sun!rusty@berkeley
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Fri 24 Feb 84 15:16:01-PST
From:      Joseph I. Pallas <PALLAS@SU-SCORE.ARPA>
To:        "sun!rusty@phoenix"@SRI-NIC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: UNIX 4.2 FIN_WAIT_2 bug fix
The problem you're describing arises from not mapping concepts
correctly.  First, there is no receiving end of a TCP connection; TCP
connections are full-duplex.  Second, neither side of a TCP connection
can close the connection, it can only close its half of the
connection, which means to announce that it will not SEND any more
data on the connection.

If the operation you are calling close results in the entire socket
structure being thrown away without receipt and acknowledgment of a
FIN and without sending a FIN and waiting for it to be ACKed, then the
operation is really an abort.  The protocol specifies clearly that a
reset should be sent immediately and the control block deleted,
leaving the connection in the closed state (any more incoming data on
the connection will be answered by resets).

As for "fixing" the sending side, IF IT AIN'T BROKEN, DON'T FIX IT!
-------
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1984 1756 PST
From:      Eric P. Scott <EPS@JPL-VLSI>
To:        TCP-IP@SRI-NIC
Subject:   The evil CCITT/ISO monster slobbers on...
I just received my "1984 Spring DECUS U.S. Symposium Registration
Information Kit."  One particular Pre-Symposium Seminar
description caught my eye: "Networks Communications & Protocols:
A Comprehensive Survey."  The abstract begins:

	This seminar is a must for entry-level and intermediate-
	level network users and managers.  This fast paced
	seminar is designed to bring you immediately up to date
	in both local area and global networking concepts.  The
	seminar is designed for both the newcomer to networking
	as well as those who haven't been briefed on new
	developments even in the last few months.  Attendees will
	gain a real sense of being on top of new developments.

Wow!

	The networking environment is emphasized in this seminar,
	beginning with a definition of communications, its
	history, and requisites.  Communications standards and
	Open Systems Interconnect are discussed in respect to
	structures, processes, systems, and architecture.  This
	leads into protocol evolution and a discussion of the
	session, presentation, and application layers.

I have a bad feeling about this, kid.

	The seminar next enters a wide-ranging exploration of
	contemporary networking strategies, global network
	structures, and transports which use X.25.  A general
	comparison is made between the capabilities of Baseband
	structured networks and Broadband networks.  The seminar
	concludes with a glimpse into the future of
	communications.

I think the seminar title is deceptive.

	Topics to be covered include:

	I.    The Electronic Tower of Babel
	      1.  Communications: A Definition
	      2.  Communications Requisites
	      3.  History of Agreement
	      4.  EIA Conformity
	      5.  ISO Draft Standards
	      6.  IEEE Resolutions
	      7.  Recent NBS Decisions
	      8.  Future Standards Forcast

	II.   Open Systems Interconnect
	      1.  Layered Structures
	      2.  Layered Processes
	      3.  Layered Systems
	      4.  OSI Layered Architecture
		  A. Physical
		  B. Link
		  C. Network
		  D. Transport
		  E. Session
		  F. Presentation
		  G. Application
	      5.  Peer Structure
	      6.  Peer Protocols
	      7.  Intermediate Nodes

	III.  Protocol Evolution
	      1.  Origins of Protocol
	      2.  ASCII Organization
	      3.  Character Structure and Parity
	      4.  VRC and LRC Checking
	      5.  CRC Error Detection
	      6.  Character Protocols
	      7.  Character Oriented Link Protocols
	      8.  Character Protocol Message Structures
	      9.  DDCMP Block Format
	      10. Major Bit Oriented Protocols
	      11. Frame Definition
	      12. Logical Station Configurations
	      13. Shared Resources

	IV.   Session Layer
	      1.  Administrative Services
	      2.  Binding and Unbinding Connections
	      3.  Dialog Services
	      4.  Control Data Exchange
	      5.  Interaction and Synchronization
	      6.  Exception Reporting

	V.    Presentation Layer
	      1.  Interpretation of Data
	      2.  Data Transformation
	      3.  Data Formatting
	      4.  Syntax Selection
	      5.  Structure of Data

	VI.   Application Layer
	      1.  Highest Layer
	      2.  Serves as Window to OSI
	      3.  Identification
	      4.  Availability of Resources
	      5.  Authority
	      6.  Authentication
	      7.  Agreement of Syntax

	VII.  Facilitating Various Networks
	      1.  Contemporary Networking Strategies
		  A. Shared Resources
		  B. Interconnected Networks
		  C. Distributed Network Facilities

	VIII. Global Network Structures
	      1.  X.24 Architecture
	      2.  X.25 Physical Layer
	      3.  X.25 Link Layer
	      4.  Packet Frame Relationships
	      5.  Logical Channel Assignment

	IX.   Transports Using X.25
	      1.  CCITT X.3/X.28 PAD
	      2.  3270 and 2780 PAD
	      3.  GTE TELENET
	      4.  TYMNET
	      5.  American Bell Net One

	X.    General Purpose Network Interface
	      1.  Architectural Relationships to OSI/NBS Models
	      2.  Domain of Local Area Networks
	      3.  Topology
	      4.  Basebound [sic] Bus
	      5.  Single-Cable Broadband Bus
	      6.  Dual-Cable Broadbad Bus
	      7.  Cambridge Ring
	      8.  Star
	      9.  LAN Access Methods
	      10. LAN Standard Options
	      11. Local Area Network Protocols
	      12. File -- File Transfer

	XI.   Physical Layer Mediums
	      1.  RS232 Characteristics
	      2.  RS449 Characteristics
	      3.  RS422 Characteristics
	      4.  Networking Mediums
		  A. 50 Ohm Coax Cable
		  B. Twisted Wire Pair
		  C. Satellite Channel
		  D. Fiber-Optics

	XII.  Applications Studies
	      1.  Implementation Examples from Industry
	      2.  Emerging Technology in Product Design

	XIII. Conclusions And Discussions

	Prerequisites:	  It is recommended that the attendees
			  have some familiarity with communica-
			  tions devices

	Instructor:	  Ken O'Mohundro is the President of ABLE
			  Computer, a dynamic and rapidly
			  expanding company devoted to network
			  enhancements.  His list of credits is
			  long, having worked as an engineer at
			  McDonnell Douglas and Interstate
			  Electronics, and then as a computer
			  designer and engineering manager for
			  Microdata.  When the opportunity to
			  become Director of Marketing operations
			  at California Data Processing appeared
			  in 1972, he took it and was grateful
			  for the challenge, for it led him to
			  found his own company in 1975.  A
			  frequent speaker at DECUS and DEXPO
			  symposia, he is also a regular
			  contributor to the DEC Professional.

	Registration fee: $175.00

Gag.
					-=EPS=-
------
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Sun 26 Feb 84 15:30:41-PST
From:      David Roode <ROODE@SRI-NIC>
To:        EPS@JPL-VLSI, TCP-IP@SRI-NIC
Subject:   Re: The evil CCITT/ISO monster slobbers on...
There is a significant body of people for whom both CCITT/ISO and
TCP/IP are unknowns.  Coming from that perspective, I think that the
most striking impression would be one of similarity rather than of
difference, since the two share underlying principles of layered
network architecture.

X.25 is linked to TCP/IP in an interesting way that has never been
documented in an RFC.  For CSNET, software has been developed under
Unix to utilize X.25 as a transport layer beneath TCP/IP.  This was
reported in:

Comer, D.  The Computer science research network CSNET: A history and
status report.  Comm. ACM, 26, 10(Oct. 1983), 747-753.

and

Comer, D.E. and Korb, J.T.  CSNET protocol software: The
IP-to-X.25 Interface. Proc. Symp. Data Comm. ACM SIGCOMM (March 1983),
154-159.
-------
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Feb 84 11:43:57 EST
From:      Jonathan Dreyer <jdreyer@BBN-UNIX>
To:        David Roode <ROODE@SRI-NIC>
Cc:        EPS@JPL-VLSI, TCP-IP@SRI-NIC
Subject:   Re: The evil CCITT/ISO monster slobbers on...
The encapsulation of IP into X.25 is described in RFC 877 by Tim Korb.
Besides the Unix implementation running at CSNet sites, there is an IBM
implementation developed at the University of Wisconsin, an implementation
running on a PDP11 (?) at University College London, and the BBN VAN
gateway running on an LSI-11.

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Mon 27 Feb 84 15:35:32-PST
From:      Ken Harrenstien <KLH@SRI-NIC>
To:        mills@DCN6
Cc:        KLH@SRI-NIC, tcp-ip@SRI-NIC
Subject:   Re: ARPANET error messages for MTI-ML
I'm not sure I understand what the problem is.  If DCN-GATEWAY is
forwarding a datagram from some non-ARPA net to the ARPANET, this
seems like something to be expected.  If it is forwarding a datagram
from the ARPANET back out to the ARPANET, why isn't DCN-GATEWAY
generating an ICMP redirect?  (If it is, then we can ask why the
source host isn't paying attention to the redirect!)

Anyway, you presumably have the ability to track this down your very
own self (and I don't see how anyone else can help you).  Just trap
any datagram which is bound for MIT-ML, and log the source address of
the IP header.  For extra veracity, log the source host/imp from the
1822 leader as well.  Then we'll have something to work on...
-------
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 84 18:33:46 EST
From:      dca-pgs @ DDN1
To:        tcp-ip@sri-nic
Cc:        dca-pgs @ DDN1
Subject:   Query: TCP/IP for Zenith Z-100


Date: 27 Feb 84 18:11:31 EST
Text: 

Is anyone out there working on a TCP/IP implementation for the Z-100?
Proteon Corp. offers a package for the IBM PC which can play into a 
BBN/Arpa gateway and thence interface DDN or Arpanet, but I haven't
heard of anything similar for the Z-100. Would love to find such a thing,
especially since, if you are Navy or Air Force, Zenith has got you 
with that big contract.

All replies appreciated.

Best,
Pat Sullivan
DCA/DDN/PMO
<dca-pgs@ddn1>

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      27-Feb-84 19:12:41-UT
From:      mills@dcn6
To:        tcp-ip@nic
Cc:        ncc@bbnu
Subject:   ARPANET error messages for MTI-ML
Folks,

Since sometime before 1700 UT on 25 February DCN-GATEWAY (10.3.0.17) has been
receiving destination-dead messages from host MIT-ML (10.3.0.6); however,
there is no record of any process in that machine generating such a message.
There is no gateway or host anywhere in the DCN-GATEWAY tables with that
address. I conclude that some outside host is sending an 1822 packet with
ARPANET leader address 3/17 and including an IP datagram with destination
address 10.3.0.6. 

Following is a trace showing the octal dump of the error messages returned
to DCN-GATEWAY from the ARPANET IMP in apparent response to sending the
IP datagram. The first line shows a "destination dead" message with sub-type
1 (destination host not up), while the second shows a "dead host status"
message with sub-type 3 (destination host does not exist). The remaining
lines are duplicates of these two. I sent an ICMP Echo message to 10.3.0.6
with the same result.


17:00:14 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633
17:00:14 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777
17:00:18 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633
17:00:18 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777
17:00:26 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633
17:00:26 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777
17:00:42 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633
17:00:42 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777
17:01:12 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633
17:01:12 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777
17:01:42 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633
17:01:43 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777
17:02:12 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633
17:02:13 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777

This sequence has been repeating at precisely half-hour intervals since
then. Notice the backoff on retransmissions, leading me to suspect the
original datagram was a TCP segment, that the connection was opened for
mail and that it timed out after two minutes.

Your help in isolating this phenomenon would be appreciated.

Dave
-------
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      28-Feb-84 20:53:17-UT
From:      mills@dcn6
To:        KenHarrenstien<KLH@SRI-NIC>, mills@DCN6, tcp-ip@SRI-NIC
Subject:   Re: ARPANET error messages for MTI-ML


Ken,

The offending datagram is apparently coming from the ARPANET and is destined
for an ARPANET host. It further apperaas thre is no other net involved, so
net-level redirects ae not called for. Your comment on tracing packets is
well taken; however, trapping datagrams by address is not presently implemented,
so cooperation from my friends, especially since this may be a generic problem,]
would be appreciated. Such trapping will be implemented, probably soon, in
any cxase.

Dave
-------

END OF DOCUMENT