The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 September 1983 11:35 EDT
From:      dca-pgs @ DDN1
To:        tcp-ip @ sri-nic
Cc:        dca-pgs @ DDN1, ddn-army @ DDN1, ddn-navy @ DDN1, ddn-usaf @ DDN1, ddn-dod @ DDN1, dcab615 @ DDN1
Subject:   New names for TCP/IP Newsletter Mailing List


Date: September 1, 1983
Text: 
To NIC Newsletter Administrator:

Please add the mailbox names listed above in the "cc" field to the 
distribution list for your TCP/IP newsletter. Also pls add
"nsi at ddn1". Thank you.

Pat Sullivan
DDN/PMO, Code B616, Subscriber Integration Branch
Defense Communications Agency
Washington, DC 20305
(703)285-5036

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 1983 12:52:02-EDT
From:      Louis A Mamakos <louie@cvl>
To:        tcp-ip@sri-nic.arpa
Subject:   Newsletter Mailing list
..could you please add   <louie@umd3>  to the newsletter mailing list?  I'm
part of the team developing the Sperry-UNIVAC 1100 TCP/IP implementation at
the University of Maryland.


        Louis A. Mamakos

	Internet:  louie@cvl.arpa
	CSNet:     louie.cvl@umcp-cs
	uucp:      ..!seismo!rlgvax!cvl!louie
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 1983 17:48:28 PDT
From:      MILLS@USC-ISID
To:        cak@PURDUE, HEDRICK@RUTGERS, tcp-ip@SRI-NIC
Cc:        MILLS@USC-ISID
Subject:   Re:  gateways, once again
In response to the message sent  7 Sep 1983 17:03:09-EST from  cak@purdue.ARPA

Chris,

EGP gateways are running now at BBN, MIT and Linkabit. Speaking for those of
us who are rummaging around in the innards, it is probably premature to
proliferate any of these three implementations. ALthough the EGP model seems
simple enough, it has turned out to be surprisingly hard to put into practice,
with all the operational constraints and lackadasical toplogy we have come to
expect. Our own implementation (DCN-GATEWAY) os [art pf the Fuzzball code and
probably is not useful in other systems. Liza Martin's version (MIT-GW?)
is written in C and may be readily portable. Mike Brescia's version (BBN-TEST)
is part of the standard core-gateway code and may represent what all the rest of f
to talk to.

I think a fair summation of the progress is that a lot of details important to
implementors, such as packet formats, protocol functions, etc., have been
stabilized; however, the "meaning" of some of the packet fields is yet in
dispute, as is the express or implied topological constraints.

Regards,
Dave
-------
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 1983 17:03:09-EST
From:      Christopher A Kent <cak@purdue.ARPA>
To:        HEDRICK@RUTGERS, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  gateways, once again
Part of the problem seems to be that the prime gateways don't 
learn about "new" networks and gateways for a long time after the
nets come up. If they would be updated regularly, then using any
prime gateway would be fine; this is the theory behind the advice
you've received.

The fact is that it sometimes takes months for prime gateways to learn
about new networks, and if you don't explicitly know about the gateway
to a particular gateway, you, ahem, can't get there from here. That's
why you need a large gateway file.

When all gateways speak EGP, this problem should go away. Funny, I haven't
heard much about EGP lately. Does anyone know the status?

Cheers,
chris
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 83 16:53:01 EDT
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   gateways, once again
Some time ago, the Authorities recommended that we should cut down our
gateway files to include only a few prime gateways.  I tried this,
together with a couple of other recommendations, and found that our
Arpanet service totally disappeared.  I did not have time to figure out
which thing I did caused the problem, so I just went back to normal
(i.e. using the whole NIC INTERNET.GATEWAYS file, and removing the other
things I had tried).  Recently I got a complaint from some folks at NYU
that we could not talk to their local hosts because we didn't know about
their gateway.  I just brought up a new gateway file that includes their
gateway.  Immediately before doing this I could not talk to NYU-CMCL1.
Immediately after, I could.  This casts serious doubt on the theory that
prime gateways are enough. Some other authority recommended that people
on the east coast might want to try the gateways file used at BBN.  I
took one from BBNB. Sure enough, it includes only a few gateways, most
of which are prime. I couldn't get through to NYU-CMCL1 with this one
either.

Once again, what gateways file should I be using?  If it is anything
other than the full table from NIC, have you really verified that you
can get to all the hosts?
-------
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 1983 20:17:03 EDT (Wednesday)
From:      Mike Brescia <brescia@BBN-UNIX>
To:        cak@purdue.ARPA
Cc:        HEDRICK@RUTGERS, tcp-ip@SRI-NIC.ARPA, brescia@BBN-UNIX, hinden@BBN-UNIX, haverty@BBN-UNIX
Subject:   Re:  gateways, once again
There seems to be an assumption in the air that the bbn gateways will
automatically and often update the portion of the routing devoted to
gateways which do not use Gateway Protocl (GGP).  The timing of the
update is not often, and only when I notice changes in the GATEWAY
lines of HOSTS.TXT (not HOST lines with more than one address),
or upon receiving a call or msg from someone close to that gateway.

Non-routing gateways have been handled rather informally in the past,
but I would appreciate information from people about their gateways and
software contacts (mail and telephone numbers).

As the MILNET split approaches, hosts on one side of the split will not
be able to reach nets on the other side if the mailbridges do not know
directly or indirectly about the gateways which reach those nets.

Mike Brescia

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 83 21:15:01 EDT
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        brescia@BBN-UNIX.ARPA
Cc:        cak@PURDUE.ARPA, tcp-ip@SRI-NIC.ARPA, hinden@BBN-UNIX.ARPA, haverty@BBN-UNIX.ARPA
Subject:   Re:  gateways, once again
I made no particular assumption about BBN.  Some expert or other
took a number of Tops-20 sites to task for using the entire NIC
gateway table.  It was asserted by a number of expets that every
prime gateway knew about every other gateway.  There was no
suggestion that this was done by informal hand updating.  I got
the impression that somehow the low-level protocols were such that
whenever a site came on the net all the prime gateways heard about
it.  Anyway, the proposal was that instead of using the NIC gateway
table, Tops-20 sites should use a short list of prime gateways, and
that this would be sufficient to let us find any other gateway.
There are serious performance reasons for wanting Tops-20 sites
to start with a short list of gateways.  The only way BBN came into
it specifically was a suggestion that BBN's Tops-20 systems had
list of prime gateways that might be useful for East-coast Tops-20
systems.  Unless somebody can point me to some prime gateways whose
management policies involve automatic updating from the NIC tables,
it looks like I will stick with using the full NIC table myself.
-------
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Thu 8 Sep 83 07:01:02-EDT
From:      Dan Tappan <Tappan@BBNG.ARPA>
To:        HEDRICK@RUTGERS.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, Tappan@BBNG.ARPA
Subject:   Re: gateways, once again
The crucial question here is whether the "gateway system" knows about
the NYU gateway. Prime gateways sufficent only if gateways communicate
with each other. Prime gateways are not sufficent for finding "dumb"
gateways that the core gateways don't know about.

When I try connecting to "NYU-CMCL1" I get a "network unreachable"
message back.  Assuming the NYU gateways is dumb, the right short term
solution was for you to add ONLY that gateway to your file. The right
long term solution is either for them to bring up a GGP|EGP gateway,
or to tell the core gateway maintainers how to get to their net
(although I've heard a rumor that eventually the core gateways will
not support routing through "dumb" gateways).

This doesn't change any of what was said before about gateways files.
To repeat Charlie Lynn's earlier message: you should have a file with
a few prime gateways PLUS any dumb gateways you need to communicate
through.

Dan
-------
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 83 1306 EDT (Thursday)
From:      don.provan@CMU-CS-A
To:        tcp-ip@SRI-NIC
Subject:   Re: gateways, once again
well, this all is a surprise.  i've been led to believe that all i
have to do to get something anywhere is to pass it off to a prime gateway.
i'm so convinced of this that the tops-10 implementation does no
routing whatsoever outside its own network.  now, from what i'm hearing,
not only do i have to do routing for networks with dumb gateways, i
have to provide a source route option on the ip packets if the dumb
gateway is on another network (as of today, no longer a hypothetical
situation).
	it's a cinch my users won't be talking to any dumb networks
any time soon.
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 1983 14:54:43-EDT
From:      Robert L Kirby <kirby@cvl>
To:        tcp-ip@sri-nic.arpa
Cc:        postmaster@cvl
Subject:   Joe Pallas has left CVL for Stanford
Please remove any of the addresses:
	joe@CVL.arpa
	joe@UMD4.arpa
	joe@UMD-CSD.arpa
	joe@UMD8.arpa
	joe@umcp.csnet
	joe@umcp-cs.csnet
	joe.cvl@umcp-cs.csnet
	joe.cvl.umcp-cs@UDEL-RELAY.arpa
	joe.umcp-cs@UDEL-RELAY.arpa
from your mailing lists.
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Thu 8 Sep 83 23:45:11-PDT
From:      David Roode <ROODE@SRI-NIC>
To:        HEDRICK@RUTGERS, tcp-ip@SRI-NIC
Subject:   Re: my conclusions from the discussion
I have one point to make prompted by a peripheral issue in your message.
Someone correct me if I am wrong, but I believe even after
we revert to the old topology, it will be safe to continue to use the new
TOPS-20 INTERNET.GATEWAYS file. The world has gained 5 more BBN-maintained
PRIME gateways for this test day, but they are planned to be around from
now on. Naturally connections to net 26 will fail, but use of
other functions of the gateway will succeed.  

I would appreciate a list of which PRIME gateways are maintained
from BBN, besides the new ARPANET/MILNET Gateways.
-------
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 1983 00:00 EST
From:      TCP-IP@brl
To:        TCP-IP@brl
Subject:   TCP-IP Digest, Vol 2 #15
TCP/IP Digest             Friday, 9 Sep 1983      Volume 2 : Issue 15

Today's Topics:
           IP on Ethernets && Pressure for IBM TCP Interfaces
             A Nearly Elegant Solution to a Gateway Problem
         TCP/IP and "Security" && Any implementations for 68000?
                   Any implementations for the IBM PC?
                   TCP/IP for VMS: not in Phoenix yet
                       TCP/IP Correctness Testing
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date: 30 Aug 1983 20:21:49 PDT
From: POSTEL@usc-isif
Subject: IP on Ethernets & Berkeley Hacks
To:   tcp-ip@brl

I have been told repeatly by the people from Berkeley (Bill Joy, Sam Leffler)
that the special hacks in the transmission of IP datagrams on the Ethernet
would only be used between consenting hosts and would never appear in a
packet addressed to a standard IP host - even on the same Ethernet.

I would like very much to have an RFC on the proper encapsulation of IP
on an Ethernet (or any other net).  If someone send me a reasonable draft
of an RFC on this i will get it "published".

--jon.

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

Date: 29 August 1983 06:36 EDT
From: ddn-army@ddn1
Subject: IBM interfaces
To: johnson%summex-aim.arpa@BRL.ARPA
CC: tcp-ip@brl.arpa

IBM marketeers are speaking to one of us with a forked tongue.  We in
the DDN PMO have identified at least 250+ customers for the IBM
interface to DDN, and have made it clear to them that we are not
interested in a one of a kind special product.  Granted we have been
dealing with Federal Systems Division people for the most part, but we
have also talked to some of their private sector types as well.  We have
been told that they are moving to market DDN interfaces as "field
service products" initially, and are having internal corporate
discussions re full product line support.  We are closely monitoring
both their VM and MVS efforts, and we are directing every DoD IBM user
to hound his local IBM rep to the grave.

We had an in-depth meeting with IBM people here in the DC area, and they
expressed concern for the strength of DoD's committment to TCP-IP.  More
importantly, they indicated they had recently particippated in a
corporate bloodlet in which ISO vice SNA was touted as the long range
architecture for IBM.  They indicated great reservation for a premature
move to tcp-ip when ISO finals appeared to be imminent.  I think
therefore, that efforts to clarify the ISO situation, and demonstrate
simularities between ISO and the DoD protocols would be more beneficial
in encouraging IBM than demands from readers of the digest.

bob

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

Date: 26 Aug 1983 11:51:34 PDT
From: PADLIPSKY@usc-isi
Subject: A Nearly Elegant Solution to a Gateway Problem
To:   tcp-ip@brl

By a curious coincidence, the very day I read the request for "TCP"/SNA
"Gateway" info was the same day I (earlier) invented the solution.  As
those of you who have read my paper on Gateways (RFC approx. 875) know,
I think so-called Translating/Mapping Gateways are a Very Bad Thing.  As
only one or two who weren't at Vint Cerf's "Futures" panel at INFOCOM
'83 know, I've come to realize
that at a sufficiently far point in the future the way to do
"interoperability" will be by running parallel protocol suites at all
the end points (preferably in suitable Outboard Processing Environments
[formerly known as NFE'S, but nobody paid enough attention to the "N"]).
That is, eventually--unless, contrary to all expectations, one protocol
suite prevails--you'll just go off to a desired application in the
appropriate suite for that appl., and to another appl. in its "home
suite"....  In the meantime, however, something more clever that trying
to yoke heterogeneous mind-sets together by the magic of the strong
assertion that it can be done is needed.

The general near-term solution that makes sense to me is what I've
called a "Janus Host".  (Two-"faced", that is; in other words it looks
to each of two different suites as if it's a "normal" Host.)  It has the
nice property of terminating each suite rather than attempting the
unattractive-in-practice "concatenation of logical connections", which
resolves probably conflicting flow control expectations, and the
additional nice property of allowing for/demanding where necessary
human/"user" intervention to resolve addressing problems.  The trick is,
in essence, to go from one suite's equivalent of User Telnet (from
anywhere) to its Server Telnet (on the Janus Host), then, via a Janus
Host application/process-level program (a "command", even) out the other
suite's generic User Telnet to the desired (generic) Server Telnet.  The
program might be thought of as a sort of transducer; anyway, if the
generic Telnets are anywhere near rightly done, all the de- and
re-virtualizing ought to happen "for free".  Indeed, FTP and Mail ought
to be doable in like manner.

Now that's all so concise as to be terse at best (and cryptic at worst),
but it does seem to me to be theoretically sound.  What good it is in
the ARM/SNA context is much more straightforward:  I know of a company
(called Spartacus Computers, actually) which is doing the Amdahl Trick
to/with VM (i.e., making a different hardware base for "the same"
software), only their box is quite inexpensive.  It also comes with
TCP/IP for their own LANning.  And there's allegedly SNA software for
VM.  Need I say any more (other than that I wish I could claim
royalties--especially when Compion realizes it could easily do the same
trick for ARM/ DECNET Janus Hosts, and whoever else is out there with
the appropriate pieces [including Dave Vinograd with HISI's own
high-rise] realizes...)?

cheers, map

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

Subject: IP/TCP and "Security"
Date: Sun, 28 Aug 83 16:19:54 EDT
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
To: tcp-ip@BRL.ARPA

Could someone explain some of the details of the MILNET split.  E.g.
since people have been talking about "mail relays/gateways" am I to
understand that you will not be able to have TCP connections between
hosts in the new MILNET network and the hosts in the present Internet
networks?  Is is the case that the new network will be an IP network,
having a unique IP network number, but will NOT actually be connected
to the current Internet via IP gateways?

[ The NIC <NIC@NIC> has some very good materials discussing the
  split in the latest DDN Newsletters.  If you are not getting copies
  contact them for a subscription.  -Mike ]

On a somewhat related topic:  have people thought out the issue of
Internet access control?  I.e. suppose I have a local net running
IP/TCP and I have all these undergraduates on machines on this net;
according to Arpa policy, only "authorized" people are supposed to
have access to the "Arpanet".  Now what does "Arpanet" means?  Just
network 10?  Any Arpa-funded networks?  Am I obliged to make my IP
gateway to network 10 prevent IP packets coming from the process of
an "unauthorized" user from leaking out?  How would such filtering
be implemented?

                            -- Nat

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

Date: Mon 29 Aug 83 09:29:05-EDT
From: Marc Shapiro <SHAPIRO@CMU-CS-C.ARPA>
Subject: 68000 protocol implementations query
To: human-nets@RUTGERS.ARPA, tcp-ip@BRL.ARPA, arpanet-bboards@MIT-MC.ARPA

Planning to implement high-level protocols on a 68000-based card
attachef to a 10 Mb/s Ethernet, I would like to get in contact with
people who have implemented eihter TCP-IP or XNS protocols on 
similar hardware (preferably in C).  We could exchnage experiences and
possibly programs.

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

Date: Tue, 30 Aug 83 11:10:45 PDT
From: Milo Medin <medin@lll-mfe>
To: tcp-ip@brl
Subject: IBM PC tcp/ip software

We here at UCB are trying to interface a couple PC's to a vax running
4.1c BSD unix.  We plan on using a 3com board to do this, but they
use XNS software and we'd prefer to keep everything TCP/IP.  I talked
to their dealer here at the PC faire, and they said MIT has the software
we need.  Anyone here know where we can get access to the software?

						Milo Medin
						medin%ucbcory@berkeley.arpa
					or	medin@lll-mfe.arpa (better)

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

Date:        Mon, 29 Aug 83 14:10:37 CDT
From: Dave Johnson <dbj.rice@rand-relay>
Subject:     Re: TCP/IP for VMS
To: TCP-IP-Digest <TCP-IP@brl>
Cc: Chris Kent <decwrl!kent%Shasta@su-score>

Chris Kent's recent message that Rice was supporting Berkeley TCP/IP under
Phoenix, our Unix emulator for VMS, was incorrect; Phoenix currently offers
no TCP/IP support.  We are, however, working on a VMS-only TCP that does not
require Phoenix to run, either by bringing up somebody else's implementation
or perhaps writing our own.  We are considering, also, sometime in the future
supporting the Berkeley 4.2 TCP/IP user interface in Phoenix by interfacing
Phoenix to this VMS TCP.  Any comments or experiences with any of the
versions of TCP/IP currently available for VMS would be welcome.

                                        Dave Johnson
                                        Dept. of Math Science
                                        Rice University
                                        dbj.rice@Rand-Relay

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

Date: 28 Aug 1983 23:29:56 EDT (Sunday)
From: Linda Seamonson <ljs@bbn-unix>
Subject: TCP/IP Correctness Testing
To: tcp-ip@brl
Cc: ljs@bbn-unix

Over the last month, several experiments were run at BBN to determine
the correctness of Arpanet host TCP/IP implementations.  Each test was
run several times to minimize the probability that a host was down
during each test; however, it is possible that some hosts scored lower
than they deserved because they were off the network during all tests.

The first experiment was conducted entirely within the Arpanet.  The
second and third experiments, however, required another network attached
to the Arpanet by more than one gateway (since the purpose of the
experiments was to test hosts' abilities to talk through gateways; see
below).  BBN has its own Arpanet-like network called the "BBNNET" which
is currently connected to the Arpanet by three gateways.  One of these
gateways, the BBN-GATEWAY, is known to the rest of the internet; it is
the gateway which is normally used by traffic between the BBNNET and the
Arpanet.  The combination of the Arpanet, the BBNNET, and the three
gateways was used as the testbed for these inter-network experiments.

There were three experiments.  The purpose of the first, Experiment A,
was to determine which hosts are unable to talk TCP even in the simplest
circumstances.  From an Arpanet host, an FTP connection was opened to
every Arpanet host (not including TACs, gateways, or secure hosts).  The
remote FTP server was then asked for "help", which causes half a screen
or so of text to be sent from the remote host to the testing host.  The
purpose of this was simply to cause a little traffic to flow on the FTP
connection.  Then the connection was closed.  This test is the simplest
possible in that it does not require the hosts to talk through a gateway
or to use ICMP.  Hosts which failed this test are labelled "4" in the
following list.  These hosts were excluded from other experiments.

The purpose of Experiment B was to determine which hosts are unable to
talk TCP to a host in another network.  From a BBNNET host, the same FTP
experiment was repeated.  Hosts failing to sustain the FTP conversation
required by this test are labelled "3" in the following list.  These
hosts can talk to hosts in their own network, but not to hosts in other
networks.  These hosts were excluded from Experiment C.

The purpose of Experiment C was to determine which hosts deal
incorrectly with redirect messages.  This experiment was just like
Experiment B, with one complication.  The BBN gateway was told to
redirect all Arpanet hosts to another gateway, "Bridge", that also
connects the Arpanet and the BBNNET.  A program called "HTM" (Host
Traffic Matrix) was run in the Bridge during this experiment.  HTM
records the source and destination of every datagram that passes through
the gateway.  Thus, after running Experiment C, the HTM results in the
Bridge listed every host that obeyed the redirects.  HTM was also run in
the BBN gateway during this experiment, and the results were used as
further proof that some hosts disregarded the redirects altogether.
Some hosts failed this test because even though they did not "choke" on
the redirects and could carry the FTP exchange to completion, they did
not pass any traffic through the Bridge (they ignored the redirects).
Other hosts failed this test because they died or hung the FTP
connection after receiving one or more redirects.  Hosts failing this
experiment are labelled "2".  Hosts passing this experiment are labelled
"1".

In summary, of 190 hosts tested, 98 scored "1" (51%), 28 scored "2"
(15%), 23 scored "3" (12%), and 41 scored "4" (22%).  Since these tests
were very simple and did not exercise all capabilities of TCP (for
example, retransmission of lost datagrams) these results are in no way
proof that all "1" hosts have perfectly correct TCP implementations.

[ The actual table was very large, and has not been included here.
  People who don't know the outcome for their host(s) should write
  to Linda.  -Mike ]

----- End of forwarded messages
------------------------------

END OF TCP-IP DIGEST
********************
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 83 02:06:47 EDT
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   my conclusions from the discussion
I have read all of your replies very carefully, and read back over the
original discussions from a few months ago.  Let me tell you what I have
concluded about pinging from all of this.  Then somebody can correct me
if I am wrong.  These comments apply only to Tops-20.  The Unix
approach, where they only ping gateways when connections actually  are
using them, seems much better and gets around these problems.

1) Claim: on Tops-20, it is never necessary to ping.
I conclude that this is false.  If the monitor uses a gateway that
happens to be down, there seems to be no way for it to know that without
pinging.  It may continue to use that gateway forever.  I conclude that
it is only necessary to ping gateways where there is an alternate
gateway that could be used to get to the same place.  If a gateway is
the only gateway and it goes down, you might as well continue trying to
use it.  Also, unless you are using source routing, it seems not to
do any good to ping gateways that are not directly attached to the
same network you are on.  It is the first gateway's job to keep track of
the rest of the route.

2) Claim: 37 sec is too often.
Well, this is a matter of taste.  However if it takes 4 times this long
to discover that a gateway is down, and if you want dynamic recovery
to occur, it does seem that this is about as long as one should ask
people to wait.  After this, programs will start timing out.

3) Claim: You only need to put prime gateways in your table.
This seems to be false.  We got responses from one manager of a prime
gateway, and he does not seem to update his tables from the NIC
tables on a regular basis.  Also our own experience suggests that
this is not happening.  Until we hear from a prime gateway that
guarantees to keep its tables up to date, we conclude that prime
gateways are only guaranteed to know about each other.

4) Claim: People on the East Coast should copy BBN's gateway
file and those on the West Coast should copy ISI's.
This is a matter of taste. The only thing is, BBN's lists only BBN
gateways and ISI's lists only ISI's gateways.  What I want is about 3
gateways scattered around the country, that are known to be reliable.
This doesn't seem a very promising start.

I conclude therefore that on Tops-20, my gateway table should
include the following:

 - a selection of prime gateways.  The others are safe to omit because
	prime gateways know about each other through GGP.  Is this
	really true?
 - all dumb and host gateways.  However it is safe to treat most of
	them as always-up (i.e. not to ping them - from the code it
	appears that the only different between dumb, host, and
	always-up is that always-up does not ping).  You only need to
	ping where there are alternate gateways, and the gateway
	involved is directly connected to your network. If you have no
	choice, you might as well not ping, since there is nothing you
	can do if you find out the gateways is down.
 - all always-up gateways

I have just written a program that traces the topology of the network
and changes gateways to always-up if there is no alternative gateway
going to the same place, or if the gateway is not directly
attached to the Arpanet.  It also purges Arpanet/Milnet gateways other
than our designated gateway, (The theory is that the others won't talk
to us.) and all prime gateways other than our designated Milnet gateway
and 2 other selected gateways. (I am using BBN-C and SRI-R2D2, for no
particular reason.  Note that I have chosen gateways that have
alternates, so that my algorithm treats them as really being prime.) The
result is that we are pinging 3 prime, 4 dumb, and 1 host  gateway,
rather than the 38 that we would do with the unaltered host table.
Furthermore, all of them are directly on the Arpanet.  This number will
go up temporarily by one when we go back to the old topology.
-------
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 1983 19:25:15 PDT
From:      POSTEL@USC-ISIF
To:        TCP-IP@SRI-NIC
Subject:   Gateway Pinging

For the information of all, here is a recent measure of the ICMP 
ECHO/ECHO-REPLY (PING) traffic between Hosts and Gateways.

--jon.

Date:  7 Sep 1983 15:41:26 EDT (Wednesday)
From: Robin Clifford <clifford@BBN-UNIX>
Subject: Gateway pinging

By way of information, I have a recent copy of Steve Cohn's ping
matrix.  It shows the message traffic between hosts and gateways.
It was taken on 1 September.

There has been a minor reduction in host pinging since the test
was run on 7 July.  However, you'll see that a substantial number
of hosts are still pinging to excess.

Robin Clifford

*****************************************************************************


          G        S C D D E  D I C I I  B P B V C  B C R C B  M S W W
          A        T M C C D  C S S S S  R U R A R  B 3 2 I B  I A A I
          T        A U N E N  E I S I I  L R A N O  N P D T N  T C S S
          E        N     C    C P   | |    D G   N  | 0 2   |      H C
          W        F       U  P S   P G    U G   U  C   +   R       
          A        O       N  S A   N W    E     S          C       
          Y        R       I  A T   G                       C       
                   D       X  T                                     
          HOST:    1 2 3 1 3  5 3 2 1 3  3 2 0 3 1  3 1 3 1 3  0 3 3 0
                                                                    
          IMP:     1 1 1 2 2  2 2 2 2 2  2 3 3 4 4  4 5 5 5 7  7 8 9 9
                   1 4 7 0 0  0 2 5 7 7  9 7 8 0 9  9 1 1 4 2  7 0 1 4
                                                                    
          HOST                                                      
          -------------------------------------------------------------
    SRI:  1/2        X X X      X X        X     X  X X X   X  X X   X
          2/2                         X                     X
    UTAH: 3/4      X X X X    X X X      X X X   X  X X X X X  X X X X
    BBN:  0/5                                  X X          X
          3/5                                  X X          X
    STAN: 3/11           X
    GUNTR:1/13     X   X X        X X X                     X      X
    CMU:  3/14     X X X X      X X      X X X   X  X X X   X  X X   X
    RADC: 3/18         X   X                 X X      X X   X  X X
    ISI:  1/22           X            X
          2/22           X            X 
    USC:  0/23         X   X                 X X    X X X   X    X
          1/23         X X      X          X X   X  X X X   X  X X   X
          3/23         X X      X          X X   X  X X X   X  X X   X
    ISI:  0/27           2            2      2
    XEROX:0/32           7            7
          3/32     X X   X    X X X   X  X X X   X  X X X X X  X X X X
    TYMSH:*/43 no pinging
    MIT:  0/44                    5   5                     5
    BBN:  0/49                                 X X          X
          3/49                                 X X          X
    ISI:  1/52           X            X  
          2/52 no traffic (host down ?)
          3/52           X            X
    CIT:  0/54     X   X X        X X X                     X      X
    SUMEX:0/56           X            X
    RUTGR:2/58     X X X X    X X X   X  X X X   X  X X X X X  X X X X
    STLA: 0/61         X X      X          X X      X X X   X  X X   X
    TEXAS:1/62           X            X
    ANDRW:0/67         X   X                 X X      X X   X  X X
    SRI:  0/73           X            X
          2/73       X X X      X X        X     X  X X X   X  X X   X
    DEC:  0/79 no traffic (host down ?)
          1/79                                 X X          X
    SANDI:0/87         X   X                 X X      X X   X  X X
    NIH:  0/88     X   X X          X      X                X
    COLUM:0/89         X X      X        X X X      X X X   X  X X   X
    WASH: 0/91     X X X X        X   X  X X X   X  X X X X X  X X X X
    TYMSH:*/93 no pinging
                                                                    
    This table shows the rate of message traffic between hosts and gateways.
    The entries are based on measurements made 03:40-03:55 (EDT) on
    1 September 1983.  (by S.Cohn)
    
    The key is as follows:
      X indicates pinging at an interval between 37 and 60 seconds.
      2,5,7 any numeral indicates a pinging interval of that many minutes.
      [ ] a blank indicates that the host does not ping that gateway.

-------
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 1983 16:32:41 PDT
From:      POSTEL@USC-ISIF
To:        tcp-ip@SRI-NIC
Subject:   On the Bad Effects of Pinging

The IMPs in the ARPANET do some resource reservation (between the source
and destination IMPs) to support the super job they do of delivering 
messages correctly, in order, etc.

There is a limited ammount of this resource.  An IMP can have only a 
limited number of reservations at a time.

If a host tries to send messages to a lot of other hosts in rapid 
succession, the IMPs have to do and undo their resource reservations 
over and over.

Sometimes it takes a while for the IMPs to complete the resource 
reservations. When this happens the IMP may "block" the host.  This 
prevents the host from sending any messages to any host for a while.

If a host send messages to a set of 10 [*] or more other hosts in quick 
succession, it virtually guarantees the host will get blocked for a 
non-trivial time every time it does this.  If a host does this once a 
minute it is virtually guaranteed that the host is geting very poor 
utilization of the ARPANET for its data traffic.

   [*] I don't know the actual number, but i am sure it is less than 10.

It is important to note that a gateway is a host from the point of view 
of the IMP, and the gateway is subject to the same blocking.  When a 
gateway has to send ECHO-REPLIES to many hosts, it too is virtually 
guaranteed to get poor utilization of the ARPANET for its data traffic.

--jon.
-------
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 1983 16:52:22 PDT
From:      POSTEL@USC-ISIF
To:        tcp-ip@SRI-NIC
Subject:   Some Ideas On a Reduced Level of Pinging

It is never useful to ping far away gateways.  Only consider pinging 
gateways on your own networks (networks you are directly attached to).

If background pinging is considered then the gateways to ping (if any) 
differ for each host.

   The "ping load" should be spread evenly across all gateways.

   One should ping independenly operated gateways (e.g., on different 
   powers systems).

   One should ping topologically and geographically nearby gateways.

There should be no background pinging.  Unless a gateway is "in use" 
there is no need to know if it is up or down.  Only when there is 
traffic to a gateway is there any need to consider pinging it.

   In ARPANET type networks (e.g., ARPANET, MILNET, MINET) the network 
   tells the host about undelivered messages, so there is no need to 
   ping in these nets.

   In other types of networks it may be useful to ping the "in use" 
   gateways.

--jon.
-------
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 1983 18:45:35 PDT
From:      POSTEL@USC-ISIF
To:        tcp-ip@SRI-NIC
Subject:   Some Comments on Gateways & Procedures

There are currently several types of gateways:

   PRIME - these talk to each other and maintain dynamic routing 
   information and have some information about some non-prime gateways.

      These are the best gateways to use.  Just about all the gateways 
      between long haul networks (ARPANET, MILNET, SATNET) are prime 
      gateways.

   DUMB - these don't do the dynamic routing stuff, so have static 
   routing tables (but maybe not complete tables), but do answer pings.

      These are usually gateways between a long haul network and a 
      "stub". A stub is a dead end, typically a single local net.  
      Usually there is no alternate gateway.

   ALWAYS-UP - these don't do dynamic routing and these don't answer 
   pings.

      Like the dumb gateways only dumber, and usually used in the same 
      way - for connecting stubs.  At least one is not tempted to ping 
      these.

The PRIME gateways use a Gateway to Gateway Protocol (GGP) to exchange 
routing information.  The GGP procedures will not be satisfactory for 
large internets.  In fact, the current number of assigned networks is 
close to the limits of GGP's capabilities.

Because the number of gateways known to the PRIME gateways impacts the 
performance of the GGP there is a motivation not to include gateways 
until they are actually ready to pass data traffic.

   Currently, the procedure for making sure a gateway is known to the 
   PRIME gateways is for the responsible person for the gateway to send 
   a computer mail message to "gateway@bbn-unix".

Changes Are Planned:

Some time in the next few months a specification for the Exterior 
Gateway Protocol (EGP) will be finalized.  Once this is done a schedule 
will be established for conversion of all gateways to this protocol.

This will mean that all gateways will have a level of knowledge about 
that of the current PRIME gateways.

--jon.
-------
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Mon 12 Sep 83 21:36:03-PDT
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Pinging, etc.
     Well, then.  We seem to have various needs at odds.  Some of us find
ourselves quite distraught when our users scream at us for not being able
to reach some network.  We find that the Prime gateways won't give us any
info about that network.  We find that the gateway for that network is
registered as "dumb".  In our never-ending attempt to follow The Official
Word, we declare said gateways as Always-Up so we don't ping it.  But, if
there is more than one eligible gateway and an Always-Up gateway is in
fact down, we find ourselves equally unable to communicate as we futilly
send messages to an unpinged dead gateway.

     Confusion is rapidly replaced by disgruntlement, and finally by
anger.  In spite of this some of us still try.  Score pings all the NIC
registered dumb gateways and two prime gateways: its assigned Milnet
gateway and another.  I don't think we're winning, but at least we may
have a chance.  Many sites don't try at all and run the vanilla NIC
gateway file.

     Can you blame us?  We have received NO useful guidelines on how to
configure one's gateway table.  We get told not to ping more than two
prime gateways, but find we can't talk to a lot of places.  We get told
to fix our kernals to not ping until that network is needed; a laudable
idea, but many of us don't have the technical skills and those of us who
do have other things to do.  After all, nobody is funding us to work on
the TOPS-20 TCP kernal; BBN and DEC are.  I thought it was claimed that
the TOPS-20 TCP was "done" over a year ago; maybe the Powers That Be want
to revise that claim?

     I claim that the NIC should provide an Officially Sanctioned gateway
table, or set of tables, with sites assigned to such-and-such a table.
Some effort should also be made to identify all the dumb and always-up
gateways to the prime gateways, so that we don't find ourselves obliged
to ping many gateways to ensure connectivity.
-------
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Mon 12 Sep 83 22:17:34-PDT
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   pinging on ARPANET
     Yes, it is true that in 1822 type networks the network tells the
host about undelivered messages, so nominally there is no need to ping
on those networks.  The problem is that many implementations of TCP,
including the TOPS-20 and Tenex one, ignore the 1822 level information
at TCP level!  As of this writing, the code to collect 1822 information
doesn't even work in the DEC kernal!

     I fixed those bugs for the Stanford TOPS-20's, but I still haven't
come up with a good way to make the IP or TCP levels use it.  A good
deal of effort is taken to insulate the IP and TCP levels from 1822, with
some justification.  To do it right would require some redesign to allow
a transmission level to communicate network/gateway/host accessibility
instead of concluding the other end isn't there by not getting any answer.

     As of right now, the 1822 information is useless on just about all
TOPS-20's but Stanford, where it's collected enough so that the Telnet
program can report a host's Type 6 status if it is down...
-------
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Mon 12 Sep 83 22:36:24-PDT
From:      David Roode <ROODE@SRI-NIC>
To:        tcp-ip@SRI-NIC
Subject:   Only PRIME gateways should ping DUMB gateways
I ask the question: if you list no DUMB gateways, nor ALWAYS-UP gateways,
would not a normal interaction with a PRIME gateway determine
the proper DUMB gateway, even if there were two alternate routes
to the same place and the first potential gateway were dead?

Are you not then causing your own problems when you list
such gateways, if your software will not robustly pass on to the next
one when the first is down, when you have the alternative
of not listing any at all and achieving correct behavior by depending
on a Prime Gateway?

Could we at least be informed of the DUMB gateways known to the
PRIME gateways, so that we can leave such DUMB gateways out of
our tables and win?  If the PRIME gateways knew all the DUMB
gateways in the current NIC host table, that would fill the bill.
Isn't this already nearly enough the truth to be assumed operant?

And furthermore, doesn't the Prime gateway when-to-ping algorithm
solve the problem of pinging too often, even if TOPS-20's IP
does not, making a good workaround for TOPS-20 sites?  I.e.,
not only can TOPS-20 IP's forego pinging DUMB gateways altogether,
but even the resulting number of pingers ping sparingly.
-------
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 1983 00:00 EST
From:      TCP-IP@brl
To:        TCP-IP@brl
Subject:   TCP-IP Digest, Vol 2 #16
TCP/IP Digest            Tuesday, 13 Oct 1983      Volume 2 : Issue 16

Today's Topics:
                      Discussion on PRIME Gateways
             Comments about first ARPA/MILNET Split Test Day
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date: 7 Sep 83 16:53:01 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: gateways, once again
To: tcp-ip@SRI-NIC.ARPA

Some time ago, the Authorities recommended that we should cut down our
gateway files to include only a few prime gateways.  I tried this,
together with a couple of other recommendations, and found that our
Arpanet service totally disappeared.  I did not have time to figure out
which thing I did caused the problem, so I just went back to normal
(i.e. using the whole NIC INTERNET.GATEWAYS file, and removing the other
things I had tried).  Recently I got a complaint from some folks at NYU
that we could not talk to their local hosts because we didn't know about
their gateway.  I just brought up a new gateway file that includes their
gateway.  Immediately before doing this I could not talk to NYU-CMCL1.
Immediately after, I could.  This casts serious doubt on the theory that
prime gateways are enough. Some other authority recommended that people
on the east coast might want to try the gateways file used at BBN.  I
took one from BBNB. Sure enough, it includes only a few gateways, most
of which are prime. I couldn't get through to NYU-CMCL1 with this one
either.

Once again, what gateways file should I be using?  If it is anything
other than the full table from NIC, have you really verified that you
can get to all the hosts?

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

Date: 7 Sep 1983 17:03:09-EST
From: Christopher A Kent <cak@purdue.ARPA>
Reply-to: cak@purdue.ARPA
To: HEDRICK@rutgers, tcp-ip@SRI-NIC.ARPA
Subject: Re:  gateways, once again

Part of the problem seems to be that the prime gateways don't 
learn about "new" networks and gateways for a long time after the
nets come up. If they would be updated regularly, then using any
prime gateway would be fine; this is the theory behind the advice
you've received.

The fact is that it sometimes takes months for prime gateways to learn
about new networks, and if you don't explicitly know about the gateway
to a particular gateway, you, ahem, can't get there from here. That's
why you need a large gateway file.

When all gateways speak EGP, this problem should go away. Funny, I haven't
heard much about EGP lately. Does anyone know the status?

Cheers,
chris

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

Date:  7 Sep 1983 20:17:03 EDT (Wednesday)
From: Mike Brescia <brescia@bbn-unix>
Subject: Re:  gateways, once again
To: cak@purdue.ARPA
Cc: HEDRICK@rutgers, tcp-ip@SRI-NIC.ARPA, brescia@bbn-unix, hinden@bbn-unix, 
    haverty@bbn-unix

There seems to be an assumption in the air that the bbn gateways will
automatically and often update the portion of the routing devoted to
gateways which do not use Gateway Protocl (GGP).  The timing of the
update is not often, and only when I notice changes in the GATEWAY
lines of HOSTS.TXT (not HOST lines with more than one address),
or upon receiving a call or msg from someone close to that gateway.

Non-routing gateways have been handled rather informally in the past,
but I would appreciate information from people about their gateways and
software contacts (mail and telephone numbers).

As the MILNET split approaches, hosts on one side of the split will not
be able to reach nets on the other side if the mailbridges do not know
directly or indirectly about the gateways which reach those nets.

Mike Brescia

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

Date:  7 Sep 1983 17:48:28 PDT
From: MILLS@usc-isid
Subject: Re:  gateways, once again
To:   cak@purdue, HEDRICK@rutgers, tcp-ip@sri-nic
cc:   MILLS@usc-isid

Chris,

EGP gateways are running now at BBN, MIT and Linkabit. Speaking for
those of us who are rummaging around in the innards, it is probably
premature to proliferate any of these three implementations. ALthough
the EGP model seems simple enough, it has turned out to be surprisingly
hard to put into practice, with all the operational constraints and
lackadasical toplogy we have come to expect. Our own implementation
(DCN-GATEWAY) os [art pf the Fuzzball code and probably is not useful in
other systems. Liza Martin's version (MIT-GW?)  is written in C and may
be readily portable. Mike Brescia's version (BBN-TEST) is part of the
standard core-gateway code and may represent what all the rest of f to
talk to.

I think a fair summation of the progress is that a lot of details
important to implementors, such as packet formats, protocol functions,
etc., have been stabilized; however, the "meaning" of some of the packet
fields is yet in dispute, as is the express or implied topological
constraints.

Regards,
Dave

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

Date: 7 Sep 83 21:15:01 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re:  gateways, once again
To: brescia@BBN-UNIX.ARPA
cc: cak@PURDUE.ARPA, tcp-ip@SRI-NIC.ARPA, hinden@BBN-UNIX.ARPA, 
    haverty@BBN-UNIX.ARPA

I made no particular assumption about BBN.  Some expert or other
took a number of Tops-20 sites to task for using the entire NIC
gateway table.  It was asserted by a number of expets that every
prime gateway knew about every other gateway.  There was no
suggestion that this was done by informal hand updating.  I got
the impression that somehow the low-level protocols were such that
whenever a site came on the net all the prime gateways heard about
it.  Anyway, the proposal was that instead of using the NIC gateway
table, Tops-20 sites should use a short list of prime gateways, and
that this would be sufficient to let us find any other gateway.
There are serious performance reasons for wanting Tops-20 sites
to start with a short list of gateways.  The only way BBN came into
it specifically was a suggestion that BBN's Tops-20 systems had
list of prime gateways that might be useful for East-coast Tops-20
systems.  Unless somebody can point me to some prime gateways whose
management policies involve automatic updating from the NIC tables,
it looks like I will stick with using the full NIC table myself.

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

Date: Thu 8 Sep 83 07:01:02-EDT
From: Dan Tappan <Tappan@BBNG.ARPA>
Subject: Re: gateways, once again
To: HEDRICK@RUTGERS.ARPA
cc: tcp-ip@SRI-NIC.ARPA, Tappan@BBNG.ARPA

The crucial question here is whether the "gateway system" knows about
the NYU gateway. Prime gateways sufficent only if gateways communicate
with each other. Prime gateways are not sufficent for finding "dumb"
gateways that the core gateways don't know about.

When I try connecting to "NYU-CMCL1" I get a "network unreachable"
message back.  Assuming the NYU gateways is dumb, the right short term
solution was for you to add ONLY that gateway to your file. The right
long term solution is either for them to bring up a GGP|EGP gateway,
or to tell the core gateway maintainers how to get to their net
(although I've heard a rumor that eventually the core gateways will
not support routing through "dumb" gateways).

This doesn't change any of what was said before about gateways files.
To repeat Charlie Lynn's earlier message: you should have a file with
a few prime gateways PLUS any dumb gateways you need to communicate
through.

Dan

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

Date:  8 Sep 83 1306 EDT (Thursday)
From: don.provan@cmu-cs-a
To: tcp-ip@sri-nic
Subject: Re: gateways, once again

Well, this all is a surprise.  I've been led to believe that all I
have to do to get something anywhere is to pass it off to a prime gateway.
I'm so convinced of this that the tops-10 implementation does no
routing whatsoever outside its own network.  Now, from what I'm hearing,
not only do I have to do routing for networks with dumb gateways, I
have to provide a source route option on the IP packets if the dumb
gateway is on another network (as of today, no longer a hypothetical
situation).

	It's a cinch my users won't be talking to any dumb networks
any time soon.

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

Date: 9 Sep 83 02:06:47 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: my conclusions from the discussion
To: tcp-ip@SRI-NIC.ARPA

I have read all of your replies very carefully, and read back over the
original discussions from a few months ago.  Let me tell you what I have
concluded about pinging from all of this.  Then somebody can correct me
if I am wrong.  These comments apply only to Tops-20.  The Unix
approach, where they only ping gateways when connections actually  are
using them, seems much better and gets around these problems.

1) Claim: on Tops-20, it is never necessary to ping.

I conclude that this is false.  If the monitor uses a gateway that
happens to be down, there seems to be no way for it to know that without
pinging.  It may continue to use that gateway forever.  I conclude that
it is only necessary to ping gateways where there is an alternate
gateway that could be used to get to the same place.  If a gateway is
the only gateway and it goes down, you might as well continue trying to
use it.  Also, unless you are using source routing, it seems not to
do any good to ping gateways that are not directly attached to the
same network you are on.  It is the first gateway's job to keep track of
the rest of the route.

2) Claim: 37 sec is too often.

Well, this is a matter of taste.  However if it takes 4 times this long
to discover that a gateway is down, and if you want dynamic recovery
to occur, it does seem that this is about as long as one should ask
people to wait.  After this, programs will start timing out.

3) Claim: You only need to put prime gateways in your table.

This seems to be false.  We got responses from one manager of a prime
gateway, and he does not seem to update his tables from the NIC
tables on a regular basis.  Also our own experience suggests that
this is not happening.  Until we hear from a prime gateway that
guarantees to keep its tables up to date, we conclude that prime
gateways are only guaranteed to know about each other.

4) Claim: People on the East Coast should copy BBN's gateway
file and those on the West Coast should copy ISI's.

This is a matter of taste. The only thing is, BBN's lists only BBN
gateways and ISI's lists only ISI's gateways.  What I want is about 3
gateways scattered around the country, that are known to be reliable.
This doesn't seem a very promising start.

I conclude therefore that on Tops-20, my gateway table should
include the following:

 - a selection of prime gateways.  The others are safe to omit because
	prime gateways know about each other through GGP.  Is this
	really true?
 - all dumb and host gateways.  However it is safe to treat most of
	them as always-up (i.e. not to ping them - from the code it
	appears that the only different between dumb, host, and
	always-up is that always-up does not ping).  You only need to
	ping where there are alternate gateways, and the gateway
	involved is directly connected to your network. If you have no
	choice, you might as well not ping, since there is nothing you
	can do if you find out the gateways is down.
 - all always-up gateways

I have just written a program that traces the topology of the network
and changes gateways to always-up if there is no alternative gateway
going to the same place, or if the gateway is not directly
attached to the Arpanet.  It also purges Arpanet/Milnet gateways other
than our designated gateway, (The theory is that the others won't talk
to us.) and all prime gateways other than our designated Milnet gateway
and 2 other selected gateways. (I am using BBN-C and SRI-R2D2, for no
particular reason.  Note that I have chosen gateways that have
alternates, so that my algorithm treats them as really being prime.) The
result is that we are pinging 3 prime, 4 dumb, and 1 host  gateway,
rather than the 38 that we would do with the unaltered host table.
Furthermore, all of them are directly on the Arpanet.  This number will
go up temporarily by one when we go back to the old topology.

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

Date: Thu 8 Sep 83 23:45:11-PDT
From: David Roode <ROODE@sri-nic>
Subject: Re: my conclusions from the discussion
To: HEDRICK@rutgers, tcp-ip@sri-nic

I have one point to make prompted by a peripheral issue in your message.
Someone correct me if I am wrong, but I believe even after we revert to
the old topology, it will be safe to continue to use the new TOPS-20
INTERNET.GATEWAYS file. The world has gained 5 more BBN-maintained PRIME
gateways for this test day, but they are planned to be around from now
on. Naturally connections to net 26 will fail, but use of other
functions of the gateway will succeed.

I would appreciate a list of which PRIME gateways are maintained from
BBN, besides the new ARPANET/MILNET Gateways.

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

Date:     Fri, 9 Sep 83 0:20:38 EDT
From:     Ron Natalie  <ron@BRL-VGR>
To:       tcp-ip@BRL-VGR, support@BRL-VGR
cc:       postel@Usc-Isif, brescia@Bbn-Unix
Subject:  MILNET/ARPANET SPLIT

Network service to the local nets BRLNET (128.20.x.x) and BRLNET1
(192.5.21.x) was unavailable during the ARPANET/MILNET split test.
Despite planning made to switch over the BRL-GATEWAY to do the
proper things we could not pass traffic to a majority of the hosts
on the net.  The reason for this problem was that even though the
gateway was prepared to be moved to MILNET (net 26) and the host port
on the imp was assigned to that COI, the BBN gateways continued to
route the subnets to the old ARPANET (net 10) address.  When BBN was
informed that the gateway was switched to the MILNET, they switched
it back for the interim.  This didn't help much because the network
topology no longer corresponded to the HOST/GATEWAY tables available
from NIC.  Hosts who derived explicit routing to the BRL-GATEWAY (or
would have liked to PING it for whatever routing) from the tables,
had their traffic turned back with the "administratively prohibitted"
message.

This demonstrates that the network split may not be transparent even to
those who load host tables regularly and fully support the Internet
Protocols.

-Ron

[ Ron informes me that as of this writing, BBN has been alerted to the
  error.  However, if there are any other dual-homed hosts or Gateways
  on the MILNET side of the split, you need to talk to Mike Brescia
  of BBN *quickly*.  -Mike]

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

END OF TCP-IP DIGEST
********************
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Tue 13 Sep 83 02:12:18-PDT
From:      Mathis@SRI-KL.ARPA
To:        MRC@SU-SCORE.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA, Mathis@SRI-KL.ARPA, nic@SRI-NIC.ARPA
Subject:   Re: Pinging, etc.

   A simple change in the way the NIC handles the gateway table may result
in a lot less pinging over the next few months until EGP gets implemented.
But first some background from a different perspective.

   There are 3 functional types of gateways: 
	- PRIME gateways, 
	- dumb or always-up gateways that are 1) the only path into a network
       	  and 2) known to the prime gateways
	- multiple dumb gateways into a network.

   Of these three types, only 1 PRIME gateway ever needs to be pinged (at a
slow interval, say every 120 secs although I don't want to start that argument 
again).  Dumb gateways known to PRIMEs never need to be pinged (so what if 
they are down, there is no other way).  Dual path dumb gateways need to be
pinged (also at a slow interval).

   The INTERNET.GATEWAY tables should be changed to have 2 types of entries:

	- PRIME gateways, pick EXACTLY 1 to ping SLOWLY
	- multiple-path dumb gateways 

(or there could be 2 tables, PRIME and multiple-path DUMB).

All dumb gateways known to PRIME gateways should be removed from the GATEWAY
table and only be listed in the HOST table with a descriptor that it is really
a gateway.  A host would not normally need to know about simple dumb gateways
that are also known to the PRIMEs (if your host doesn't process REDIRECTS--go
to your room without dinner).

Individual hosts could filter their own table until the NIC gets around
to a new table, except that most people don't know which dumb gateways are
known to the PRIMEs.  To help get the information around, when a new gateway
owner wants to register a gateway, the NIC should notify BBN about the new
gateway.  The user, BBN and NIC should then decide if the PRIMES can know
about the dumb gateway or if it is multiple path gateway that needs to go
in the table to be pinged.


-------
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 83 03:58:36 EDT
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        ROODE@SRI-NIC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Only PRIME gateways should ping DUMB gateways
the problem with DUMB gateways having alternates is what happens if
the one you choose goes down while you are using it.  Unless your
monitor tells you when a packet is undeliverable, your connection
will just hang.  The PRIME gateway only helps when you first make
the connection.
-------
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 1983 10:21:59 PDT
From:      POSTEL@USC-ISIF
To:        TCP-ip@SRI-NIC
Subject:   Official Policy or Buggy Procedure ?

Folks:

The tone of many of the recent messages on gateway routing, pinging, table
updates, etc. seems to take on the feel that certain things have been done
according to a mysterious official policy determined by the nameless them.

It is much more likely that there are bugs in the procedures, that information
that should have been communicated wasn't, or that someone forgot to do
something.

For example, there is this discussion on the importance of pinging dumb
gateways.  One part of the discussion is concered with the fact that for
a time one dumb gateway was not in the set that the prime gateways know
about.  Part of the discussion is based on the assumption that this will
often be the case and therefore hosts have to keep all dumb gateways in
there tables (and possibly ping them).

I think it is more likely that the gateway in question was left out due to
a error or noncommunication.  I think it is a bug in procedures that should
be fixed once, rather that having many hosts do resource consuming things
all the time.

--jon.
-------
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Tue 13 Sep 83 12:47:03-PDT
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        ROODE@SRI-NIC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Only PRIME gateways should ping DUMB gateways
Roode's statement that PRIME gateways should know about all DUMB
gateways is laudable.  Many of us assumed it was reality.
Unfortunately, it isn't.  Were it to become reality (and be guaranteed
as such), it would make the pinging problem academic.  Every site could
be given its officially assigned two PRIME gateways and that would be
that.
-------
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue 13 Sep 83 17:01:48-PDT
From:      Mathis@SRI-KL.ARPA
To:        brescia@BBN-UNIX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, Mathis@SRI-KL.ARPA
Subject:   Re: Core, GGP, and non-GGP gateways; a list
Mike,
   The gateway list also needs to be trimmed of gateways that are essentally
useless for general internet routing purposes.  For example, I don't think
the various SIMP and PSAT gateways should be included since those gateways
are essentially for internal test use.  Is there a SATNET/WB NET position
on whether those gateways should be included if we assume that any gateway
not known to the BBN/GGP gateways should be pinged?
Jim
-------
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 1983 17:28:08 EDT (Tuesday)
From:      Mike Brescia <brescia@BBN-UNIX>
To:        tcp-ip@nic
Cc:        brescia@BBN-UNIX
Subject:   Core, GGP, and non-GGP gateways; a list
Following gateway lines are from [nic]<netinfo>hosts.txt.307.  I have
prefixed the following codes on these lines to indicate some information
used in the BBN gateways (sometimes called 'core gateways').

I hope this will help table maintainers chose gateways for pinging, and
prompt people to advise of gateways which should not be overlooked.

I have made no attempt to define the meaning or use of the terms PRIME,
DUMB, or ALWAYS-UP.  As far as I can tell from the listing, they have
not been consistent.  There are PSAT 'gateways' which are shown as DUMB,
and others as ALWAYS-UP.  There are PRIME systems listed which do not
participate in GGP routing, do not forward packets, or do not issue ICMP
redirect messages.

Mike Brescia

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

BBN - gateway code supported by BBN.  There are 24 listed.

GGP - exchange GGP routing info with some BBN gateways. There are 3.

NR  - known to some BBN gateways as 'non-routing' (non-GGP) paths to
    some net(s).  Note: these are NOT pinged.  There are 8 listed, and
    in addition, there are NR gateways with addresses 10.0.0.25,
    10.1.0.77, and 10.2.0.78.

BBN GATEWAY : 1.0.0.11, 3.0.0.62 : BBN-PR-GATEWAY :: MOS : IP/GW,GW/PRIME :
BBN GATEWAY : 4.0.0.38, 48.0.0.4, 50.0.0.4 : NTARE-GATEWAY,NTA-GATEWAY,NDRE
BBN GATEWAY : 4.0.0.60, 32.3.0.42, 35.7.0.0, 128.16.0.0 : UCL-GATEWAY,GOONH
BBN GATEWAY : 4.0.0.76 : DFVLR-GATEWAY : LSI-11/23 : MOS : IP/GW,GW/PRIME :
    GATEWAY : 4.0.0.92 : FUCINO-IG : H-316 : SIMP : IP/GW :
BBN GATEWAY : 8.3.0.14, 192.1.2.1 : BBN-FIBER-GATEWAY,BBN-FIBER,FIBER : LSI
NR  GATEWAY : 10.3.0.2, 39.128.1.230 : SRINET-GATEWAY :: UNIX : IP/GW,GW/DU
NR  GATEWAY : 10.0.0.4, 192.5.12.21 : UTAH-GATEWAY : VAX-11/750 : UNIX : IP
    GATEWAY : 10.2.0.5, 3.2.0.5 : BBN-PTIP-GATEWAY,BBN-RCC : PLURIBUS :: IP
BBN GATEWAY : 10.5.0.5, 26.2.0.49 : BBN-MILNET-GWY,MILBBN,BBN-MILNET-GW : L
    GATEWAY : 10.3.0.10, 28.9.0.0 : LL-PSAT-IG,LL-11 ::: IP/GW,GW/DUMB :
    GATEWAY : 10.5.0.10, 28.18.0.0, 28.19.0.0 : LL-GW : PDP-11/44 : EPOS : 
NR  GATEWAY : 10.1.0.11, 36.40.0.62 : STANFORD-GATEWAY : LSI-11/23 : MOS : 
NR  GATEWAY : 10.2.0.14, 128.2.254.36 : CMU-GATEWAY : PDP-11/40 :: IP/GW,GW
GGP GATEWAY : 10.3.0.17, 128.4.0.1, 128.5.0.1, 128.8.0.1 : DCN-GATEWAY : LS
BBN GATEWAY : 10.1.0.20, 128.19.0.2, 4.0.0.24 : DCEC-GATEWAY,EDN-GATEWAY : 
    GATEWAY : 10.5.0.20, 28.10.0.0 : DCEC-PSAT-IG ::: IP/GW,GW/ALWAYS-UP :
BBN GATEWAY : 10.7.0.20, 26.0.0.104 : DCEC-MILNET-GWY,MILDCEC,DCEC-MILNET-G
BBN GATEWAY : 10.2.0.22, 26.0.0.103 : ISI-MILNET-GWY,MILISI,ISI-MILNET-GW :
    GATEWAY : 10.3.0.22, 28.8.0.0 : ISI-PSAT-IG ::: IP/GW,GW/DUMB :
BBN GATEWAY : 10.2.0.25, 4.0.0.61 : CSS-GATEWAY : PDP-11/40 : MOS : IP/GW,G
BBN GATEWAY : 10.3.0.27, 128.9.0.81 : ISI-GATEWAY,ISI-GW : PDP-11/23 : MOS 
BBN GATEWAY : 10.2.0.28, 26.0.0.106 : ARPA-MILNET-GWY,MILARPA,ARPA-MILNET-G
BBN GATEWAY : 10.2.0.37, 128.10.0.3 : PURDUE-CS-GW : PDP-11/34 : MOS : IP/G
BBN GATEWAY : 10.0.0.38, 9.0.0.11 : BRAGG-GWY1 : LSI-11/2 : MOS : IP/GW,GW/
BBN GATEWAY : 10.3.0.38 : NET-5-GATEWAY : LSI-11/2 : MOS : IP :
BBN GATEWAY : 10.1.0.49, 128.11.0.1, 192.1.2.3 : BBN-CGTWY,CGTWY,CRONUS : L
    GATEWAY : 10.5.0.49, 4.0.0.30 : CLARKSBURG-IG : C/30 : SIMP : IP/GW,GW/
BBN GATEWAY : 10.1.0.51, 128.21.0.11 : SRI-C3P0 : LSI-11/2 : MOS : IP/GW,GW
    GATEWAY : 10.1.3.51, 28.11.0.0 : SRI-PSAT-IG ::: IP/GW,GW/ALWAYS-UP :
BBN GATEWAY : 10.3.0.51, 45.0.0.11, 128.21.0.12 : SRI-R2D2 : LSI-11/2 : MOS
BBN GATEWAY : 10.4.0.51, 26.2.0.73 : SRI-MILNET-GWY,MILSRI,SRI-MILNET-GW : 
NR  GATEWAY : 10.1.0.54, 192.5.7.2 : CIT-CS-GW : VAX-11/780 : UNIX : IP/GW,
BBN GATEWAY : 10.3.0.72, 8.3.0.8 : BBN-NET-GATEWAY,BBN-RCC-GATEWAY : LSI-11
GGP GATEWAY : 10.0.0.77, 18.10.0.4 : MIT-GW,MIT-GATEWAY : PDP-11 : MOS : IP
BBN GATEWAY : 10.2.0.80, 26.0.0.105 : SAC-MILNET-GWY,MILSAC,SAC-MILNET-GW :
BBN GATEWAY : 10.3.0.80, 47.0.0.11 : SAC-GATEWAY,SAC-GW,SAC-GWY1 : PDP-11/2
NR  GATEWAY : 10.3.0.91, 192.5.8.5 : UW-VLSI-GW : VAX-11/780 : UNIX : IP/GW
BBN GATEWAY : 10.0.0.94, 192.5.2.6 : WISC-GATEWAY : PDP-11/34 : MOS : IP/GW
    GATEWAY : 10.3.0.96, 192.5.36.5 : CORNELL-GW : VAX-11/780 : UNIX : IP/G
BBN GATEWAY : 14.0.0.10 : BBN-VAN-GW ::::
GGP GATEWAY : 25.6.0.0, 25.13.0.0, 35.6.0.0 : RSRE-GATEWAY :: EMMOS : IP/GW
    GATEWAY : 26.1.0.18, 28.12.0.0 : RADC-PSAT-IG : PLURIBUS :: IP/GW,GW/AL
    GATEWAY : 26.0.0.29, 192.5.22.2 : BRL-GATEWAY2 :: UNIX : IP/GW,GW/DUMB 
NR  GATEWAY : 26.3.0.29, 192.5.21.5, 128.20.0.1, 192.5.25.2 : BRL-GATEWAY :
NR  GATEWAY : 26.0.0.58, 192.5.15.129 : NYU-GW : VAX-11/780 : UNIX : IP/GW,
    GATEWAY : 26.0.0.81, 192.5.27.0 : DTNSRDC-GW : VAX-11/750 : UNIX : IP/G
    GATEWAY : 26.3.0.81, 192.5.26.0 : NSRDCOA-GW : VAX-11/750 : UNIX : IP/G
    GATEWAY : 128.10.0.2, 14.0.0.1 : CSNET-PURDUE-GW : VAX-11/780 : UNIX : 

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Sep 83 2:44:43 EDT
From:      Mike Muuss <mike@brl-vgr>
To:        Mike Brescia <brescia@bbn-unix>
Cc:        tcp-ip@sri-nic, brescia@bbn-unix
Subject:   Re:  Core, GGP, and non-GGP gateways; a list
Hey!  Don't forget the BRL-GATEWAY, a non-routing gateway connecting

10.3.0.29, 128.20.0.1, 192.5.21.5,

and BRL-GATEWAY2, a non-routing gateway (+host) connecting

10.0.0.29, 192.5.22.2, and (soon) 128.20.0.2

Note that the 10 (arpanet) will become 26 after the milnet split.
		-Mike
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1983 1022-PDT
From:      Ian H. Merritt <MERRITT@USC-ISIB>
To:        Mathis@SRI-KL.ARPA
Cc:        brescia@BBN-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Core, GGP, and non-GGP gateways; a list
I agree it is not a good idea to be pinging WBnet gateways.  Since these
are, at least for the moment, primarly used for experiments, often
including traffic measurements, pinging could distort the results.
Though the access to the internet could be disabled for most
experiments, the WBnet is not yet available for reliable or even
semi-reliable service, and should not really be known about by any
machines not directly participating in the experiments.

					Ian H. Merritt
					Wideband Communications Project
					USC/ISI
-------
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1983 12:10:53-EST
From:      Christopher A Kent <cak@purdue>
To:        POSTEL@USC-ISIF
Cc:        tcp-ip@SRI-NIC
Subject:   Re: Some Comments on Gateways & Procedures
I think it's great that all this stored up knowledge is finally making
it into the open. I have learned a lot about this by having to figure
it out (I have had some willing tutors, scattered across the internet)
in order to keep my users happy and keep my "worked-all-nets" certificate
up to date.

There is at least one additional type of gateway -- the gateway that 
understands (some) GGP, reroutes packets, and speaks full ICMP, but
isn't one of the "core" gateways supported by BBN and participating
in the full GGP conversation. The gateway that I built for the BBN
VAX TCP is one of these; I believe that the standalone gateway at
CMU is also. The MIT C-Gateway may be as well.

Thus, the people that use "my" gateway at their site list it as both
DUMB and PRIME, depending on their intent. If an errant datagram makes
its way to one of these gateways, bound for a network to which the
gateway is not connected, it will send a redirect and route the
'gram appropriately, if it knows how (if it's in the NIC's table,
it probably knows how). So it's not a true stub gateway. It responds
to both GGP and ICMP Pings, so it's not a DUMB or ALWAYS-UP. But
it doesn't send or receive GGP routing updates, so it's not really
PRIME, either.

I have as many of the gateways listed with NIC installed in my tables
as possible; we don't ping gateways unless we're using them, and 
don't in general seem to have too much trouble getting to networks
far and wide. If the core gateways would update their tables to know
about new stub gateways more quickly, I think we would be saved
an awful lot of grief.

Cheers,
chris

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Wed 14 Sep 83 19:51:53-PDT
From:      David Roode <ROODE@SRI-NIC>
To:        dca-pgs@DDN1, tcp-ip@SRI-NIC
Cc:        dca-pgs@DDN1, ddn-army@DDN1, ddn-navy@DDN1, ddn-usaf@DDN1, ddn-dod@DDN1, dcab615@DDN1, TCP-IP-REQUEST@SRI-NIC, HSS@SRI-NIC, NIC@SRI-NIC
Subject:   Re: New names for TCP/IP Newsletter Mailing List
The following have been added to TCP-IP@NIC  (the mailing distribution
list):

ddn-army@DDN1,
dcab615@DDN1,
ddn-dod@DDN1,
ddn-navy@DDN1,
dca-pgs@DDN1,
ddn-usaf@DDN1,
nsi@ddn1,

For any problems or any other subscription-related correspondance,
please use the address TCP-IP-REQUEST@SRI-NIC .
-------
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 1983 00:00 EST
From:      TCP-IP@brl
To:        TCP-IP@brl
Subject:   TCP-IP Digest, Vol 2 #17
TCP/IP Digest          Thursday, 22 Sept 1983      Volume 2 : Issue 17

Today's Topics:
                    IP on Ethernets with 4.2 BSD UNIX
                              XNS for UNIX?
                  MIT TCP/IP for IBM Peronal Computers
               Lengthy discussion of Pinging and Gateways
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date: 13 Sep 1983 09:37:58 PDT
From: POSTEL@usc-isif
Subject: IP on Ethernets & Berkeley Hacks
To:   tcp-ip-digest@brl

From: karels%ucbarpa@Berkeley (Mike Karels)
Date: 13 Sep 1983 0926-PDT (Tuesday)
To: POSTEL@USC-ISIF
Cc: mosher@Berkeley
Subject: Re: Special Hacks vs. Standard Hosts

It is now very easy to turn off both trailer protocols and address resolution
protocol.  The ifconfig program, run at boot time to set the local network
address, allows those options to be set or cleared.  It is possible to
use both ARP and the "old" address mapping dependent on the address range,
but this does require changing the value of a global variable to specify
the boundary between them.  Also, as part of the ARP implementation,
there is a way of asking about the ability to do trailer encapsulation,
and thus ARP hosts that do not do trailers should be handled transparently.
Given that it is so easy to disable trailers, I don't think there should
be any concern about compatibility.  I will be adding a section on this
to the installation and operation manual.

		Mike

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

Date:           Fri, 16 Sep 83 14:33:55 PDT
From:           Rich Wales <v.wales@ucla-locus>
To:             TCP-IP@brl
Subject:        XNS for UNIX?

Does anyone know of implementations of the Xerox Network Systems (XNS)
protocols under 4.1BSD UNIX?

I have had a couple of people tell me about a company called Network
Research Corporation in Los Angeles which supposedly has an XNS imple-
mentation, but I would like to know if there are any others available.

-- Rich Wales <wales@UCLA-LOCUS>

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

Date: 21 Sep 1983 20:19:11-PDT
From: John L. Romkey <romkey%MIT-BORAX@mit-multics>
To: TCP-IP@brl
Subject: MIT TCP/IP for IBM PC's

I have been working for about one and a half years on MIT's TCP/IP for the
PC (with the 3COM ethernet interface). The programs work, but we're not set
up to distribute them. We started work on them as a research project, but
there is a lot of demand for this type of program. Unfortunately, we're not
set up to distribute and maintain the programs for a large number of users.
We are currently trying to arrange for the code to be both available and
supported. As soon as we make any progress in this area, we'll make an
announcement here.

Please don't deluge me with requests for the programs or the sources. If you
really MUST have a copy, contact Jerry Saltzer (Saltzer@Mit-Multics). I can
answer technical questions about the programs, though.
                                                            - John Romkey
                                                              romkey@mit-borax

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

Date: 13 Sep 1983 10:21:59 PDT
From: POSTEL@usc-isif
Subject: Official Policy or Buggy Procedure ?
To:   TCP-ip@sri-nic

Folks:

The tone of many of the recent messages on gateway routing, pinging,
table updates, etc. seems to take on the feel that certain things have
been done according to a mysterious official policy determined by the
nameless them.

It is much more likely that there are bugs in the procedures, that
information that should have been communicated wasn't, or that someone
forgot to do something.

For example, there is this discussion on the importance of pinging dumb
gateways.  One part of the discussion is concered with the fact that for
a time one dumb gateway was not in the set that the prime gateways know
about.  Part of the discussion is based on the assumption that this will
often be the case and therefore hosts have to keep all dumb gateways in
there tables (and possibly ping them).

I think it is more likely that the gateway in question was left out due
to a error or noncommunication.  I think it is a bug in procedures that
should be fixed once, rather that having many hosts do resource
consuming things all the time.

--jon.

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

Date: 12 Sep 1983 18:45:35 PDT
From: POSTEL@usc-isif
Subject: Some Comments on Gateways & Procedures
To:   tcp-ip@sri-nic

There are currently several types of gateways:

   PRIME - these talk to each other and maintain dynamic routing 
   information and have some information about some non-prime gateways.

      These are the best gateways to use.  Just about all the gateways 
      between long haul networks (ARPANET, MILNET, SATNET) are prime 
      gateways.

   DUMB - these don't do the dynamic routing stuff, so have static 
   routing tables (but maybe not complete tables), but do answer pings.

      These are usually gateways between a long haul network and a 
      "stub". A stub is a dead end, typically a single local net.  
      Usually there is no alternate gateway.

   ALWAYS-UP - these don't do dynamic routing and these don't answer 
   pings.

      Like the dumb gateways only dumber, and usually used in the same 
      way - for connecting stubs.  At least one is not tempted to ping 
      these.

The PRIME gateways use a Gateway to Gateway Protocol (GGP) to exchange 
routing information.  The GGP procedures will not be satisfactory for 
large internets.  In fact, the current number of assigned networks is 
close to the limits of GGP's capabilities.

Because the number of gateways known to the PRIME gateways impacts the 
performance of the GGP there is a motivation not to include gateways 
until they are actually ready to pass data traffic.

   Currently, the procedure for making sure a gateway is known to the 
   PRIME gateways is for the responsible person for the gateway to send 
   a computer mail message to "gateway@bbn-unix".

Changes Are Planned:

Some time in the next few months a specification for the Exterior 
Gateway Protocol (EGP) will be finalized.  Once this is done a schedule 
will be established for conversion of all gateways to this protocol.

This will mean that all gateways will have a level of knowledge about 
that of the current PRIME gateways.

--jon.

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

Date: Mon 12 Sep 83 22:17:34-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: pinging on ARPANET
To: TCP-IP@SRI-NIC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Yes, it is true that in 1822 type networks the network tells the
host about undelivered messages, so nominally there is no need to ping
on those networks.  The problem is that many implementations of TCP,
including the TOPS-20 and Tenex one, ignore the 1822 level information
at TCP level!  As of this writing, the code to collect 1822 information
doesn't even work in the DEC kernal!

     I fixed those bugs for the Stanford TOPS-20's, but I still haven't
come up with a good way to make the IP or TCP levels use it.  A good
deal of effort is taken to insulate the IP and TCP levels from 1822, with
some justification.  To do it right would require some redesign to allow
a transmission level to communicate network/gateway/host accessibility
instead of concluding the other end isn't there by not getting any answer.

     As of right now, the 1822 information is useless on just about all
TOPS-20's but Stanford, where it's collected enough so that the Telnet
program can report a host's Type 6 status if it is down...

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

Date: Mon 12 Sep 83 22:36:24-PDT
From: David Roode <ROODE@sri-nic>
Subject: Only PRIME gateways should ping DUMB gateways
To: tcp-ip@sri-nic
Location:  EJ286    Phone: (415) 859-2774

I ask the question: if you list no DUMB gateways, nor ALWAYS-UP gateways,
would not a normal interaction with a PRIME gateway determine
the proper DUMB gateway, even if there were two alternate routes
to the same place and the first potential gateway were dead?

Are you not then causing your own problems when you list
such gateways, if your software will not robustly pass on to the next
one when the first is down, when you have the alternative
of not listing any at all and achieving correct behavior by depending
on a Prime Gateway?

Could we at least be informed of the DUMB gateways known to the
PRIME gateways, so that we can leave such DUMB gateways out of
our tables and win?  If the PRIME gateways knew all the DUMB
gateways in the current NIC host table, that would fill the bill.
Isn't this already nearly enough the truth to be assumed operant?

And furthermore, doesn't the Prime gateway when-to-ping algorithm
solve the problem of pinging too often, even if TOPS-20's IP
does not, making a good workaround for TOPS-20 sites?  I.e.,
not only can TOPS-20 IP's forego pinging DUMB gateways altogether,
but even the resulting number of pingers ping sparingly.

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

Date: Mon 12 Sep 83 21:36:03-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Pinging, etc.
To: TCP-IP@SRI-NIC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Well, then.  We seem to have various needs at odds.  Some of us find
ourselves quite distraught when our users scream at us for not being able
to reach some network.  We find that the Prime gateways won't give us any
info about that network.  We find that the gateway for that network is
registered as "dumb".  In our never-ending attempt to follow The Official
Word, we declare said gateways as Always-Up so we don't ping it.  But, if
there is more than one eligible gateway and an Always-Up gateway is in
fact down, we find ourselves equally unable to communicate as we futilly
send messages to an unpinged dead gateway.

     Confusion is rapidly replaced by disgruntlement, and finally by
anger.  In spite of this some of us still try.  Score pings all the NIC
registered dumb gateways and two prime gateways: its assigned Milnet
gateway and another.  I don't think we're winning, but at least we may
have a chance.  Many sites don't try at all and run the vanilla NIC
gateway file.

     Can you blame us?  We have received NO useful guidelines on how to
configure one's gateway table.  We get told not to ping more than two
prime gateways, but find we can't talk to a lot of places.  We get told
to fix our kernals to not ping until that network is needed; a laudable
idea, but many of us don't have the technical skills and those of us who
do have other things to do.  After all, nobody is funding us to work on
the TOPS-20 TCP kernal; BBN and DEC are.  I thought it was claimed that
the TOPS-20 TCP was "done" over a year ago; maybe the Powers That Be want
to revise that claim?

     I claim that the NIC should provide an Officially Sanctioned gateway
table, or set of tables, with sites assigned to such-and-such a table.
Some effort should also be made to identify all the dumb and always-up
gateways to the prime gateways, so that we don't find ourselves obliged
to ping many gateways to ensure connectivity.

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

Date: 11 Sep 1983 19:25:15 PDT
From: POSTEL@usc-isif
Subject: Gateway Pinging
To:   TCP-IP@sri-nic

For the information of all, here is a recent measure of the ICMP 
ECHO/ECHO-REPLY (PING) traffic between Hosts and Gateways.

--jon.

Date:  7 Sep 1983 15:41:26 EDT (Wednesday)
From: Robin Clifford <clifford@BBN-UNIX>
Subject: Gateway pinging

By way of information, I have a recent copy of Steve Cohn's ping
matrix.  It shows the message traffic between hosts and gateways.
It was taken on 1 September.

There has been a minor reduction in host pinging since the test
was run on 7 July.  However, you'll see that a substantial number
of hosts are still pinging to excess.

Robin Clifford

*****************************************************************************


          G        S C D D E  D I C I I  B P B V C  B C R C B  M S W W
          A        T M C C D  C S S S S  R U R A R  B 3 2 I B  I A A I
          T        A U N E N  E I S I I  L R A N O  N P D T N  T C S S
          E        N     C    C P   | |    D G   N  | 0 2   |      H C
          W        F       U  P S   P G    U G   U  C   +   R       
          A        O       N  S A   N W    E     S          C       
          Y        R       I  A T   G                       C       
                   D       X  T                                     
          HOST:    1 2 3 1 3  5 3 2 1 3  3 2 0 3 1  3 1 3 1 3  0 3 3 0
                                                                    
          IMP:     1 1 1 2 2  2 2 2 2 2  2 3 3 4 4  4 5 5 5 7  7 8 9 9
                   1 4 7 0 0  0 2 5 7 7  9 7 8 0 9  9 1 1 4 2  7 0 1 4
                                                                    
          HOST                                                      
          -------------------------------------------------------------
    SRI:  1/2        X X X      X X        X     X  X X X   X  X X   X
          2/2                         X                     X
    UTAH: 3/4      X X X X    X X X      X X X   X  X X X X X  X X X X
    BBN:  0/5                                  X X          X
          3/5                                  X X          X
    STAN: 3/11           X
    GUNTR:1/13     X   X X        X X X                     X      X
    CMU:  3/14     X X X X      X X      X X X   X  X X X   X  X X   X
    RADC: 3/18         X   X                 X X      X X   X  X X
    ISI:  1/22           X            X
          2/22           X            X 
    USC:  0/23         X   X                 X X    X X X   X    X
          1/23         X X      X          X X   X  X X X   X  X X   X
          3/23         X X      X          X X   X  X X X   X  X X   X
    ISI:  0/27           2            2      2
    XEROX:0/32           7            7
          3/32     X X   X    X X X   X  X X X   X  X X X X X  X X X X
    TYMSH:*/43 no pinging
    MIT:  0/44                    5   5                     5
    BBN:  0/49                                 X X          X
          3/49                                 X X          X
    ISI:  1/52           X            X  
          2/52 no traffic (host down ?)
          3/52           X            X
    CIT:  0/54     X   X X        X X X                     X      X
    SUMEX:0/56           X            X
    RUTGR:2/58     X X X X    X X X   X  X X X   X  X X X X X  X X X X
    STLA: 0/61         X X      X          X X      X X X   X  X X   X
    TEXAS:1/62           X            X
    ANDRW:0/67         X   X                 X X      X X   X  X X
    SRI:  0/73           X            X
          2/73       X X X      X X        X     X  X X X   X  X X   X
    DEC:  0/79 no traffic (host down ?)
          1/79                                 X X          X
    SANDI:0/87         X   X                 X X      X X   X  X X
    NIH:  0/88     X   X X          X      X                X
    COLUM:0/89         X X      X        X X X      X X X   X  X X   X
    WASH: 0/91     X X X X        X   X  X X X   X  X X X X X  X X X X
    TYMSH:*/93 no pinging
                                                                    
    This table shows the rate of message traffic between hosts and gateways.
    The entries are based on measurements made 03:40-03:55 (EDT) on
    1 September 1983.  (by S.Cohn)
    
    The key is as follows:
      X indicates pinging at an interval between 37 and 60 seconds.
      2,5,7 any numeral indicates a pinging interval of that many minutes.
      [ ] a blank indicates that the host does not ping that gateway.

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

Date: 12 Sep 1983 16:32:41 PDT
From: POSTEL@usc-isif
Subject: On the Bad Effects of Pinging
To:   tcp-ip@sri-nic

The IMPs in the ARPANET do some resource reservation (between the source
and destination IMPs) to support the super job they do of delivering 
messages correctly, in order, etc.

There is a limited ammount of this resource.  An IMP can have only a 
limited number of reservations at a time.

If a host tries to send messages to a lot of other hosts in rapid 
succession, the IMPs have to do and undo their resource reservations 
over and over.

Sometimes it takes a while for the IMPs to complete the resource 
reservations. When this happens the IMP may "block" the host.  This 
prevents the host from sending any messages to any host for a while.

If a host send messages to a set of 10 [*] or more other hosts in quick 
succession, it virtually guarantees the host will get blocked for a 
non-trivial time every time it does this.  If a host does this once a 
minute it is virtually guaranteed that the host is geting very poor 
utilization of the ARPANET for its data traffic.

   [*] I don't know the actual number, but i am sure it is less than 10.

It is important to note that a gateway is a host from the point of view 
of the IMP, and the gateway is subject to the same blocking.  When a 
gateway has to send ECHO-REPLIES to many hosts, it too is virtually 
guaranteed to get poor utilization of the ARPANET for its data traffic.

--jon.

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

Date: 12 Sep 1983 16:52:22 PDT
From: POSTEL@usc-isif
Subject: Some Ideas On a Reduced Level of Pinging
To:   tcp-ip@sri-nic

It is never useful to ping far away gateways.  Only consider pinging 
gateways on your own networks (networks you are directly attached to).

If background pinging is considered then the gateways to ping (if any) 
differ for each host.

   The "ping load" should be spread evenly across all gateways.

   One should ping independenly operated gateways (e.g., on different 
   powers systems).

   One should ping topologically and geographically nearby gateways.

There should be no background pinging.  Unless a gateway is "in use" 
there is no need to know if it is up or down.  Only when there is 
traffic to a gateway is there any need to consider pinging it.

   In ARPANET type networks (e.g., ARPANET, MILNET, MINET) the network 
   tells the host about undelivered messages, so there is no need to 
   ping in these nets.

   In other types of networks it may be useful to ping the "in use" 
   gateways.

--jon.

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

Date: 13 Sep 83 03:58:36 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Only PRIME gateways should ping DUMB gateways
To: ROODE@SRI-NIC.ARPA
cc: tcp-ip@SRI-NIC.ARPA

The problem with DUMB gateways having alternates is what happens if
the one you choose goes down while you are using it.  Unless your
monitor tells you when a packet is undeliverable, your connection
will just hang.  The PRIME gateway only helps when you first make
the connection.

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

Date: Tue 13 Sep 83 02:12:18-PDT
From: Mathis@SRI-KL.ARPA
Subject: Re: Pinging, etc.
To: MRC@SU-SCORE.ARPA
cc: TCP-IP@SRI-NIC.ARPA, Mathis@SRI-KL.ARPA, nic@SRI-NIC.ARPA

   A simple change in the way the NIC handles the gateway table may result
in a lot less pinging over the next few months until EGP gets implemented.
But first some background from a different perspective.

   There are 3 functional types of gateways: 
	- PRIME gateways, 
	- dumb or always-up gateways that are 1) the only path into a network
       	  and 2) known to the prime gateways
	- multiple dumb gateways into a network.

   Of these three types, only 1 PRIME gateway ever needs to be pinged (at a
slow interval, say every 120 secs although I don't want to start that argument 
again).  Dumb gateways known to PRIMEs never need to be pinged (so what if 
they are down, there is no other way).  Dual path dumb gateways need to be
pinged (also at a slow interval).

   The INTERNET.GATEWAY tables should be changed to have 2 types of entries:

	- PRIME gateways, pick EXACTLY 1 to ping SLOWLY
	- multiple-path dumb gateways 

(or there could be 2 tables, PRIME and multiple-path DUMB).

All dumb gateways known to PRIME gateways should be removed from the GATEWAY
table and only be listed in the HOST table with a descriptor that it is really
a gateway.  A host would not normally need to know about simple dumb gateways
that are also known to the PRIMEs (if your host doesn't process REDIRECTS--go
to your room without dinner).

Individual hosts could filter their own table until the NIC gets around
to a new table, except that most people don't know which dumb gateways are
known to the PRIMEs.  To help get the information around, when a new gateway
owner wants to register a gateway, the NIC should notify BBN about the new
gateway.  The user, BBN and NIC should then decide if the PRIMES can know
about the dumb gateway or if it is multiple path gateway that needs to go
in the table to be pinged.

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

Date: 13 Sep 1983 17:28:08 EDT (Tuesday)
From: Mike Brescia <brescia@bbn-unix>
Subject: Core, GGP, and non-GGP gateways; a list
To: tcp-ip@nic
Cc: brescia@bbn-unix

Following gateway lines are from [nic]<netinfo>hosts.txt.307.  I have
prefixed the following codes on these lines to indicate some information
used in the BBN gateways (sometimes called 'core gateways').

I hope this will help table maintainers chose gateways for pinging, and
prompt people to advise of gateways which should not be overlooked.

I have made no attempt to define the meaning or use of the terms PRIME,
DUMB, or ALWAYS-UP.  As far as I can tell from the listing, they have
not been consistent.  There are PSAT 'gateways' which are shown as DUMB,
and others as ALWAYS-UP.  There are PRIME systems listed which do not
participate in GGP routing, do not forward packets, or do not issue ICMP
redirect messages.

Mike Brescia

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

BBN - gateway code supported by BBN.  There are 24 listed.

GGP - exchange GGP routing info with some BBN gateways. There are 3.

NR  - known to some BBN gateways as 'non-routing' (non-GGP) paths to
    some net(s).  Note: these are NOT pinged.  There are 8 listed, and
    in addition, there are NR gateways with addresses 10.0.0.25,
    10.1.0.77, and 10.2.0.78.

BBN GATEWAY : 1.0.0.11, 3.0.0.62 : BBN-PR-GATEWAY :: MOS : IP/GW,GW/PRIME :
BBN GATEWAY : 4.0.0.38, 48.0.0.4, 50.0.0.4 : NTARE-GATEWAY,NTA-GATEWAY,NDRE
BBN GATEWAY : 4.0.0.60, 32.3.0.42, 35.7.0.0, 128.16.0.0 : UCL-GATEWAY,GOONH
BBN GATEWAY : 4.0.0.76 : DFVLR-GATEWAY : LSI-11/23 : MOS : IP/GW,GW/PRIME :
    GATEWAY : 4.0.0.92 : FUCINO-IG : H-316 : SIMP : IP/GW :
BBN GATEWAY : 8.3.0.14, 192.1.2.1 : BBN-FIBER-GATEWAY,BBN-FIBER,FIBER : LSI
NR  GATEWAY : 10.3.0.2, 39.128.1.230 : SRINET-GATEWAY :: UNIX : IP/GW,GW/DU
NR  GATEWAY : 10.0.0.4, 192.5.12.21 : UTAH-GATEWAY : VAX-11/750 : UNIX : IP
    GATEWAY : 10.2.0.5, 3.2.0.5 : BBN-PTIP-GATEWAY,BBN-RCC : PLURIBUS :: IP
BBN GATEWAY : 10.5.0.5, 26.2.0.49 : BBN-MILNET-GWY,MILBBN,BBN-MILNET-GW : L
    GATEWAY : 10.3.0.10, 28.9.0.0 : LL-PSAT-IG,LL-11 ::: IP/GW,GW/DUMB :
    GATEWAY : 10.5.0.10, 28.18.0.0, 28.19.0.0 : LL-GW : PDP-11/44 : EPOS : 
NR  GATEWAY : 10.1.0.11, 36.40.0.62 : STANFORD-GATEWAY : LSI-11/23 : MOS : 
NR  GATEWAY : 10.2.0.14, 128.2.254.36 : CMU-GATEWAY : PDP-11/40 :: IP/GW,GW
GGP GATEWAY : 10.3.0.17, 128.4.0.1, 128.5.0.1, 128.8.0.1 : DCN-GATEWAY : LS
BBN GATEWAY : 10.1.0.20, 128.19.0.2, 4.0.0.24 : DCEC-GATEWAY,EDN-GATEWAY : 
    GATEWAY : 10.5.0.20, 28.10.0.0 : DCEC-PSAT-IG ::: IP/GW,GW/ALWAYS-UP :
BBN GATEWAY : 10.7.0.20, 26.0.0.104 : DCEC-MILNET-GWY,MILDCEC,DCEC-MILNET-G
BBN GATEWAY : 10.2.0.22, 26.0.0.103 : ISI-MILNET-GWY,MILISI,ISI-MILNET-GW :
    GATEWAY : 10.3.0.22, 28.8.0.0 : ISI-PSAT-IG ::: IP/GW,GW/DUMB :
BBN GATEWAY : 10.2.0.25, 4.0.0.61 : CSS-GATEWAY : PDP-11/40 : MOS : IP/GW,G
BBN GATEWAY : 10.3.0.27, 128.9.0.81 : ISI-GATEWAY,ISI-GW : PDP-11/23 : MOS 
BBN GATEWAY : 10.2.0.28, 26.0.0.106 : ARPA-MILNET-GWY,MILARPA,ARPA-MILNET-G
BBN GATEWAY : 10.2.0.37, 128.10.0.3 : PURDUE-CS-GW : PDP-11/34 : MOS : IP/G
BBN GATEWAY : 10.0.0.38, 9.0.0.11 : BRAGG-GWY1 : LSI-11/2 : MOS : IP/GW,GW/
BBN GATEWAY : 10.3.0.38 : NET-5-GATEWAY : LSI-11/2 : MOS : IP :
BBN GATEWAY : 10.1.0.49, 128.11.0.1, 192.1.2.3 : BBN-CGTWY,CGTWY,CRONUS : L
    GATEWAY : 10.5.0.49, 4.0.0.30 : CLARKSBURG-IG : C/30 : SIMP : IP/GW,GW/
BBN GATEWAY : 10.1.0.51, 128.21.0.11 : SRI-C3P0 : LSI-11/2 : MOS : IP/GW,GW
    GATEWAY : 10.1.3.51, 28.11.0.0 : SRI-PSAT-IG ::: IP/GW,GW/ALWAYS-UP :
BBN GATEWAY : 10.3.0.51, 45.0.0.11, 128.21.0.12 : SRI-R2D2 : LSI-11/2 : MOS
BBN GATEWAY : 10.4.0.51, 26.2.0.73 : SRI-MILNET-GWY,MILSRI,SRI-MILNET-GW : 
NR  GATEWAY : 10.1.0.54, 192.5.7.2 : CIT-CS-GW : VAX-11/780 : UNIX : IP/GW,
BBN GATEWAY : 10.3.0.72, 8.3.0.8 : BBN-NET-GATEWAY,BBN-RCC-GATEWAY : LSI-11
GGP GATEWAY : 10.0.0.77, 18.10.0.4 : MIT-GW,MIT-GATEWAY : PDP-11 : MOS : IP
BBN GATEWAY : 10.2.0.80, 26.0.0.105 : SAC-MILNET-GWY,MILSAC,SAC-MILNET-GW :
BBN GATEWAY : 10.3.0.80, 47.0.0.11 : SAC-GATEWAY,SAC-GW,SAC-GWY1 : PDP-11/2
NR  GATEWAY : 10.3.0.91, 192.5.8.5 : UW-VLSI-GW : VAX-11/780 : UNIX : IP/GW
BBN GATEWAY : 10.0.0.94, 192.5.2.6 : WISC-GATEWAY : PDP-11/34 : MOS : IP/GW
    GATEWAY : 10.3.0.96, 192.5.36.5 : CORNELL-GW : VAX-11/780 : UNIX : IP/G
BBN GATEWAY : 14.0.0.10 : BBN-VAN-GW ::::
GGP GATEWAY : 25.6.0.0, 25.13.0.0, 35.6.0.0 : RSRE-GATEWAY :: EMMOS : IP/GW
    GATEWAY : 26.1.0.18, 28.12.0.0 : RADC-PSAT-IG : PLURIBUS :: IP/GW,GW/AL
    GATEWAY : 26.0.0.29, 192.5.22.2 : BRL-GATEWAY2 :: UNIX : IP/GW,GW/DUMB 
NR  GATEWAY : 26.3.0.29, 192.5.21.5, 128.20.0.1, 192.5.25.2 : BRL-GATEWAY :
NR  GATEWAY : 26.0.0.58, 192.5.15.129 : NYU-GW : VAX-11/780 : UNIX : IP/GW,
    GATEWAY : 26.0.0.81, 192.5.27.0 : DTNSRDC-GW : VAX-11/750 : UNIX : IP/G
    GATEWAY : 26.3.0.81, 192.5.26.0 : NSRDCOA-GW : VAX-11/750 : UNIX : IP/G
    GATEWAY : 128.10.0.2, 14.0.0.1 : CSNET-PURDUE-GW : VAX-11/780 : UNIX : 

[ Don't forget BRL-GATEWAY and BRL-GATEWAY2 !  -Mike ]

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

Date: Tue 13 Sep 83 12:47:03-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Only PRIME gateways should ping DUMB gateways
To: ROODE@SRI-NIC.ARPA
cc: tcp-ip@SRI-NIC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Roode's statement that PRIME gateways should know about all DUMB
gateways is laudable.  Many of us assumed it was reality.
Unfortunately, it isn't.  Were it to become reality (and be guaranteed
as such), it would make the pinging problem academic.  Every site could
be given its officially assigned two PRIME gateways and that would be
that.

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

Date: Tue 13 Sep 83 17:01:48-PDT
From: Mathis@SRI-KL.ARPA
Subject: Re: Core, GGP, and non-GGP gateways; a list
To: brescia@BBN-UNIX.ARPA
cc: tcp-ip@SRI-NIC.ARPA, Mathis@SRI-KL.ARPA

   The gateway list also needs to be trimmed of gateways that are essentally
useless for general internet routing purposes.  For example, I don't think
the various SIMP and PSAT gateways should be included since those gateways
are essentially for internal test use.  Is there a SATNET/WB NET position
on whether those gateways should be included if we assume that any gateway
not known to the BBN/GGP gateways should be pinged?
Jim

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

Date: 14 Sep 1983 12:10:53-EST
From: Christopher A Kent <cak@purdue>
Reply-to: cak@purdue
To: POSTEL@usc-isif
cc: tcp-ip@sri-nic
Subject: Re: Some Comments on Gateways & Procedures

I think it's great that all this stored up knowledge is finally making
it into the open. I have learned a lot about this by having to figure
it out (I have had some willing tutors, scattered across the internet)
in order to keep my users happy and keep my "worked-all-nets" certificate
up to date.

There is at least one additional type of gateway -- the gateway that 
understands (some) GGP, reroutes packets, and speaks full ICMP, but
isn't one of the "core" gateways supported by BBN and participating
in the full GGP conversation. The gateway that I built for the BBN
VAX TCP is one of these; I believe that the standalone gateway at
CMU is also. The MIT C-Gateway may be as well.

Thus, the people that use "my" gateway at their site list it as both
DUMB and PRIME, depending on their intent. If an errant datagram makes
its way to one of these gateways, bound for a network to which the
gateway is not connected, it will send a redirect and route the
'gram appropriately, if it knows how (if it's in the NIC's table,
it probably knows how). So it's not a true stub gateway. It responds
to both GGP and ICMP Pings, so it's not a DUMB or ALWAYS-UP. But
it doesn't send or receive GGP routing updates, so it's not really
PRIME, either.

I have as many of the gateways listed with NIC installed in my tables
as possible; we don't ping gateways unless we're using them, and 
don't in general seem to have too much trouble getting to networks
far and wide. If the core gateways would update their tables to know
about new stub gateways more quickly, I think we would be saved
an awful lot of grief.

Cheers,
chris

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

Date: 14 Sep 1983 1022-PDT
Subject: Re: Core, GGP, and non-GGP gateways; a list
From: Ian H. Merritt <MERRITT@usc-isib>
To: Mathis@SRI-KL.ARPA
cc: brescia@BBN-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA

I agree it is not a good idea to be pinging WBnet gateways.  Since these
are, at least for the moment, primarly used for experiments, often
including traffic measurements, pinging could distort the results.
Though the access to the internet could be disabled for most
experiments, the WBnet is not yet available for reliable or even
semi-reliable service, and should not really be known about by any
machines not directly participating in the experiments.

					Ian H. Merritt
					Wideband Communications Project
					USC/ISI

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

END OF TCP-IP DIGEST
********************
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-Sep-83 09:05:14 EDT
From:      TCP-IP%brl@brl-bmd.UUCP (TCP-IP@brl)
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 2 #17


TCP/IP Digest          Thursday, 22 Sept 1983      Volume 2 : Issue 17

Today's Topics:
                    IP on Ethernets with 4.2 BSD UNIX
                              XNS for UNIX?
                  MIT TCP/IP for IBM Peronal Computers
               Lengthy discussion of Pinging and Gateways
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date: 13 Sep 1983 09:37:58 PDT
From: POSTEL@usc-isif
Subject: IP on Ethernets & Berkeley Hacks
To:   tcp-ip-digest@brl

From: karels%ucbarpa@Berkeley (Mike Karels)
Date: 13 Sep 1983 0926-PDT (Tuesday)
To: POSTEL@USC-ISIF
Cc: mosher@Berkeley
Subject: Re: Special Hacks vs. Standard Hosts

It is now very easy to turn off both trailer protocols and address resolution
protocol.  The ifconfig program, run at boot time to set the local network
address, allows those options to be set or cleared.  It is possible to
use both ARP and the "old" address mapping dependent on the address range,
but this does require changing the value of a global variable to specify
the boundary between them.  Also, as part of the ARP implementation,
there is a way of asking about the ability to do trailer encapsulation,
and thus ARP hosts that do not do trailers should be handled transparently.
Given that it is so easy to disable trailers, I don't think there should
be any concern about compatibility.  I will be adding a section on this
to the installation and operation manual.

		Mike

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

Date:           Fri, 16 Sep 83 14:33:55 PDT
From:           Rich Wales <v.wales@ucla-locus>
To:             TCP-IP@brl
Subject:        XNS for UNIX?

Does anyone know of implementations of the Xerox Network Systems (XNS)
protocols under 4.1BSD UNIX?

I have had a couple of people tell me about a company called Network
Research Corporation in Los Angeles which supposedly has an XNS imple-
mentation, but I would like to know if there are any others available.

-- Rich Wales <wales@UCLA-LOCUS>

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

Date: 21 Sep 1983 20:19:11-PDT
From: John L. Romkey <romkey%MIT-BORAX@mit-multics>
To: TCP-IP@brl
Subject: MIT TCP/IP for IBM PC's

I have been working for about one and a half years on MIT's TCP/IP for the
PC (with the 3COM ethernet interface). The programs work, but we're not set
up to distribute them. We started work on them as a research project, but
there is a lot of demand for this type of program. Unfortunately, we're not
set up to distribute and maintain the programs for a large number of users.
We are currently trying to arrange for the code to be both available and
supported. As soon as we make any progress in this area, we'll make an
announcement here.

Please don't deluge me with requests for the programs or the sources. If you
really MUST have a copy, contact Jerry Saltzer (Saltzer@Mit-Multics). I can
answer technical questions about the programs, though.
                                                            - John Romkey
                                                              romkey@mit-borax

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

Date: 13 Sep 1983 10:21:59 PDT
From: POSTEL@usc-isif
Subject: Official Policy or Buggy Procedure ?
To:   TCP-ip@sri-nic

Folks:

The tone of many of the recent messages on gateway routing, pinging,
table updates, etc. seems to take on the feel that certain things have
been done according to a mysterious official policy determined by the
nameless them.

It is much more likely that there are bugs in the procedures, that
information that should have been communicated wasn't, or that someone
forgot to do something.

For example, there is this discussion on the importance of pinging dumb
gateways.  One part of the discussion is concered with the fact that for
a time one dumb gateway was not in the set that the prime gateways know
about.  Part of the discussion is based on the assumption that this will
often be the case and therefore hosts have to keep all dumb gateways in
there tables (and possibly ping them).

I think it is more likely that the gateway in question was left out due
to a error or noncommunication.  I think it is a bug in procedures that
should be fixed once, rather that having many hosts do resource
consuming things all the time.

--jon.

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

Date: 12 Sep 1983 18:45:35 PDT
From: POSTEL@usc-isif
Subject: Some Comments on Gateways & Procedures
To:   tcp-ip@sri-nic

There are currently several types of gateways:

   PRIME - these talk to each other and maintain dynamic routing
   information and have some information about some non-prime gateways.

      These are the best gateways to use.  Just about all the gateways
      between long haul networks (ARPANET, MILNET, SATNET) are prime
      gateways.

   DUMB - these don't do the dynamic routing stuff, so have static
   routing tables (but maybe not complete tables), but do answer pings.

      These are usually gateways between a long haul network and a
      "stub". A stub is a dead end, typically a single local net.
      Usually there is no alternate gateway.

   ALWAYS-UP - these don't do dynamic routing and these don't answer
   pings.

      Like the dumb gateways only dumber, and usually used in the same
      way - for connecting stubs.  At least one is not tempted to ping
      these.

The PRIME gateways use a Gateway to Gateway Protocol (GGP) to exchange
routing information.  The GGP procedures will not be satisfactory for
large internets.  In fact, the current number of assigned networks is
close to the limits of GGP's capabilities.

Because the number of gateways known to the PRIME gateways impacts the
performance of the GGP there is a motivation not to include gateways
until they are actually ready to pass data traffic.

   Currently, the procedure for making sure a gateway is known to the
   PRIME gateways is for the responsible person for the gateway to send
   a computer mail message to "gateway@bbn-unix".

Changes Are Planned:

Some time in the next few months a specification for the Exterior
Gateway Protocol (EGP) will be finalized.  Once this is done a schedule
will be established for conversion of all gateways to this protocol.

This will mean that all gateways will have a level of knowledge about
that of the current PRIME gateways.

--jon.

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

Date: Mon 12 Sep 83 22:17:34-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: pinging on ARPANET
To: TCP-IP@SRI-NIC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Yes, it is true that in 1822 type networks the network tells the
host about undelivered messages, so nominally there is no need to ping
on those networks.  The problem is that many implementations of TCP,
including the TOPS-20 and Tenex one, ignore the 1822 level information
at TCP level!  As of this writing, the code to collect 1822 information
doesn't even work in the DEC kernal!

     I fixed those bugs for the Stanford TOPS-20's, but I still haven't
come up with a good way to make the IP or TCP levels use it.  A good
deal of effort is taken to insulate the IP and TCP levels from 1822, with
some justification.  To do it right would require some redesign to allow
a transmission level to communicate network/gateway/host accessibility
instead of concluding the other end isn't there by not getting any answer.

     As of right now, the 1822 information is useless on just about all
TOPS-20's but Stanford, where it's collected enough so that the Telnet
program can report a host's Type 6 status if it is down...

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

Date: Mon 12 Sep 83 22:36:24-PDT
From: David Roode <ROODE@sri-nic>
Subject: Only PRIME gateways should ping DUMB gateways
To: tcp-ip@sri-nic
Location:  EJ286    Phone: (415) 859-2774

I ask the question: if you list no DUMB gateways, nor ALWAYS-UP gateways,
would not a normal interaction with a PRIME gateway determine
the proper DUMB gateway, even if there were two alternate routes
to the same place and the first potential gateway were dead?

Are you not then causing your own problems when you list
such gateways, if your software will not robustly pass on to the next
one when the first is down, when you have the alternative
of not listing any at all and achieving correct behavior by depending
on a Prime Gateway?

Could we at least be informed of the DUMB gateways known to the
PRIME gateways, so that we can leave such DUMB gateways out of
our tables and win?  If the PRIME gateways knew all the DUMB
gateways in the current NIC host table, that would fill the bill.
Isn't this already nearly enough the truth to be assumed operant?

And furthermore, doesn't the Prime gateway when-to-ping algorithm
solve the problem of pinging too often, even if TOPS-20's IP
does not, making a good workaround for TOPS-20 sites?  I.e.,
not only can TOPS-20 IP's forego pinging DUMB gateways altogether,
but even the resulting number of pingers ping sparingly.

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

Date: Mon 12 Sep 83 21:36:03-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Pinging, etc.
To: TCP-IP@SRI-NIC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Well, then.  We seem to have various needs at odds.  Some of us find
ourselves quite distraught when our users scream at us for not being able
to reach some network.  We find that the Prime gateways won't give us any
info about that network.  We find that the gateway for that network is
registered as "dumb".  In our never-ending attempt to follow The Official
Word, we declare said gateways as Always-Up so we don't ping it.  But, if
there is more than one eligible gateway and an Always-Up gateway is in
fact down, we find ourselves equally unable to communicate as we futilly
send messages to an unpinged dead gateway.

     Confusion is rapidly replaced by disgruntlement, and finally by
anger.  In spite of this some of us still try.  Score pings all the NIC
registered dumb gateways and two prime gateways: its assigned Milnet
gateway and another.  I don't think we're winning, but at least we may
have a chance.  Many sites don't try at all and run the vanilla NIC
gateway file.

     Can you blame us?  We have received NO useful guidelines on how to
configure one's gateway table.  We get told not to ping more than two
prime gateways, but find we can't talk to a lot of places.  We get told
to fix our kernals to not ping until that network is needed; a laudable
idea, but many of us don't have the technical skills and those of us who
do have other things to do.  After all, nobody is funding us to work on
the TOPS-20 TCP kernal; BBN and DEC are.  I thought it was claimed that
the TOPS-20 TCP was "done" over a year ago; maybe the Powers That Be want
to revise that claim?

     I claim that the NIC should provide an Officially Sanctioned gateway
table, or set of tables, with sites assigned to such-and-such a table.
Some effort should also be made to identify all the dumb and always-up
gateways to the prime gateways, so that we don't find ourselves obliged
to ping many gateways to ensure connectivity.

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

Date: 11 Sep 1983 19:25:15 PDT
From: POSTEL@usc-isif
Subject: Gateway Pinging
To:   TCP-IP@sri-nic

For the information of all, here is a recent measure of the ICMP
ECHO/ECHO-REPLY (PING) traffic between Hosts and Gateways.

--jon.

Date:  7 Sep 1983 15:41:26 EDT (Wednesday)
From: Robin Clifford <clifford@BBN-UNIX>
Subject: Gateway pinging

By way of information, I have a recent copy of Steve Cohn's ping
matrix.  It shows the message traffic between hosts and gateways.
It was taken on 1 September.

There has been a minor reduction in host pinging since the test
was run on 7 July.  However, you'll see that a substantial number
of hosts are still pinging to excess.

Robin Clifford

*****************************************************************************


          G        S C D D E  D I C I I  B P B V C  B C R C B  M S W W
          A        T M C C D  C S S S S  R U R A R  B 3 2 I B  I A A I
          T        A U N E N  E I S I I  L R A N O  N P D T N  T C S S
          E        N     C    C P   | |    D G   N  | 0 2   |      H C
          W        F       U  P S   P G    U G   U  C   +   R
          A        O       N  S A   N W    E     S          C
          Y        R       I  A T   G                       C
                   D       X  T
          HOST:    1 2 3 1 3  5 3 2 1 3  3 2 0 3 1  3 1 3 1 3  0 3 3 0

          IMP:     1 1 1 2 2  2 2 2 2 2  2 3 3 4 4  4 5 5 5 7  7 8 9 9
                   1 4 7 0 0  0 2 5 7 7  9 7 8 0 9  9 1 1 4 2  7 0 1 4

          HOST
          -------------------------------------------------------------
    SRI:  1/2        X X X      X X        X     X  X X X   X  X X   X
          2/2                         X                     X
    UTAH: 3/4      X X X X    X X X      X X X   X  X X X X X  X X X X
    BBN:  0/5                                  X X          X
          3/5                                  X X          X
    STAN: 3/11           X
    GUNTR:1/13     X   X X        X X X                     X      X
    CMU:  3/14     X X X X      X X      X X X   X  X X X   X  X X   X
    RADC: 3/18         X   X                 X X      X X   X  X X
    ISI:  1/22           X            X
          2/22           X            X
    USC:  0/23         X   X                 X X    X X X   X    X
          1/23         X X      X          X X   X  X X X   X  X X   X
          3/23         X X      X          X X   X  X X X   X  X X   X
    ISI:  0/27           2            2      2
    XEROX:0/32           7            7
          3/32     X X   X    X X X   X  X X X   X  X X X X X  X X X X
    TYMSH:*/43 no pinging
    MIT:  0/44                    5   5                     5
    BBN:  0/49                                 X X          X
          3/49                                 X X          X
    ISI:  1/52           X            X
          2/52 no traffic (host down ?)
          3/52           X            X
    CIT:  0/54     X   X X        X X X                     X      X
    SUMEX:0/56           X            X
    RUTGR:2/58     X X X X    X X X   X  X X X   X  X X X X X  X X X X
    STLA: 0/61         X X      X          X X      X X X   X  X X   X
    TEXAS:1/62           X            X
    ANDRW:0/67         X   X                 X X      X X   X  X X
    SRI:  0/73           X            X
          2/73       X X X      X X        X     X  X X X   X  X X   X
    DEC:  0/79 no traffic (host down ?)
          1/79                                 X X          X
    SANDI:0/87         X   X                 X X      X X   X  X X
    NIH:  0/88     X   X X          X      X                X
    COLUM:0/89         X X      X        X X X      X X X   X  X X   X
    WASH: 0/91     X X X X        X   X  X X X   X  X X X X X  X X X X
    TYMSH:*/93 no pinging

    This table shows the rate of message traffic between hosts and gateways.
    The entries are based on measurements made 03:40-03:55 (EDT) on
    1 September 1983.  (by S.Cohn)

    The key is as follows:
      X indicates pinging at an interval between 37 and 60 seconds.
      2,5,7 any numeral indicates a pinging interval of that many minutes.
      [ ] a blank indicates that the host does not ping that gateway.

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

Date: 12 Sep 1983 16:32:41 PDT
From: POSTEL@usc-isif
Subject: On the Bad Effects of Pinging
To:   tcp-ip@sri-nic

The IMPs in the ARPANET do some resource reservation (between the source
and destination IMPs) to support the super job they do of delivering
messages correctly, in order, etc.

There is a limited ammount of this resource.  An IMP can have only a
limited number of reservations at a time.

If a host tries to send messages to a lot of other hosts in rapid
succession, the IMPs have to do and undo their resource reservations
over and over.

Sometimes it takes a while for the IMPs to complete the resource
reservations. When this happens the IMP may "block" the host.  This
prevents the host from sending any messages to any host for a while.

If a host send messages to a set of 10 [*] or more other hosts in quick
succession, it virtually guarantees the host will get blocked for a
non-trivial time every time it does this.  If a host does this once a
minute it is virtually guaranteed that the host is geting very poor
utilization of the ARPANET for its data traffic.

   [*] I don't know the actual number, but i am sure it is less than 10.

It is important to note that a gateway is a host from the point of view
of the IMP, and the gateway is subject to the same blocking.  When a
gateway has to send ECHO-REPLIES to many hosts, it too is virtually
guaranteed to get poor utilization of the ARPANET for its data traffic.

--jon.

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

Date: 12 Sep 1983 16:52:22 PDT
From: POSTEL@usc-isif
Subject: Some Ideas On a Reduced Level of Pinging
To:   tcp-ip@sri-nic

It is never useful to ping far away gateways.  Only consider pinging
gateways on your own networks (networks you are directly attached to).

If background pinging is considered then the gateways to ping (if any)
differ for each host.

   The "ping load" should be spread evenly across all gateways.

   One should ping independenly operated gateways (e.g., on different
   powers systems).

   One should ping topologically and geographically nearby gateways.

There should be no background pinging.  Unless a gateway is "in use"
there is no need to know if it is up or down.  Only when there is
traffic to a gateway is there any need to consider pinging it.

   In ARPANET type networks (e.g., ARPANET, MILNET, MINET) the network
   tells the host about undelivered messages, so there is no need to
   ping in these nets.

   In other types of networks it may be useful to ping the "in use"
   gateways.

--jon.

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

Date: 13 Sep 83 03:58:36 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Only PRIME gateways should ping DUMB gateways
To: ROODE@SRI-NIC.ARPA
cc: tcp-ip@SRI-NIC.ARPA

The problem with DUMB gateways having alternates is what happens if
the one you choose goes down while you are using it.  Unless your
monitor tells you when a packet is undeliverable, your connection
will just hang.  The PRIME gateway only helps when you first make
the connection.

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

Date: Tue 13 Sep 83 02:12:18-PDT
From: Mathis@SRI-KL.ARPA
Subject: Re: Pinging, etc.
To: MRC@SU-SCORE.ARPA
cc: TCP-IP@SRI-NIC.ARPA, Mathis@SRI-KL.ARPA, nic@SRI-NIC.ARPA

   A simple change in the way the NIC handles the gateway table may result
in a lot less pinging over the next few months until EGP gets implemented.
But first some background from a different perspective.

   There are 3 functional types of gateways:
	- PRIME gateways,
	- dumb or always-up gateways that are 1) the only path into a network
       	  and 2) known to the prime gateways
	- multiple dumb gateways into a network.

   Of these three types, only 1 PRIME gateway ever needs to be pinged (at a
slow interval, say every 120 secs although I don't want to start that argument
again).  Dumb gateways known to PRIMEs never need to be pinged (so what if
they are down, there is no other way).  Dual path dumb gateways need to be
pinged (also at a slow interval).

   The INTERNET.GATEWAY tables should be changed to have 2 types of entries:

	- PRIME gateways, pick EXACTLY 1 to ping SLOWLY
	- multiple-path dumb gateways

(or there could be 2 tables, PRIME and multiple-path DUMB).

All dumb gateways known to PRIME gateways should be removed from the GATEWAY
table and only be listed in the HOST table with a descriptor that it is really
a gateway.  A host would not normally need to know about simple dumb gateways
that are also known to the PRIMEs (if your host doesn't process REDIRECTS--go
to your room without dinner).

Individual hosts could filter their own table until the NIC gets around
to a new table, except that most people don't know which dumb gateways are
known to the PRIMEs.  To help get the information around, when a new gateway
owner wants to register a gateway, the NIC should notify BBN about the new
gateway.  The user, BBN and NIC should then decide if the PRIMES can know
about the dumb gateway or if it is multiple path gateway that needs to go
in the table to be pinged.

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

Date: 13 Sep 1983 17:28:08 EDT (Tuesday)
From: Mike Brescia <brescia@bbn-unix>
Subject: Core, GGP, and non-GGP gateways; a list
To: tcp-ip@nic
Cc: brescia@bbn-unix

Following gateway lines are from [nic]<netinfo>hosts.txt.307.  I have
prefixed the following codes on these lines to indicate some information
used in the BBN gateways (sometimes called 'core gateways').

I hope this will help table maintainers chose gateways for pinging, and
prompt people to advise of gateways which should not be overlooked.

I have made no attempt to define the meaning or use of the terms PRIME,
DUMB, or ALWAYS-UP.  As far as I can tell from the listing, they have
not been consistent.  There are PSAT 'gateways' which are shown as DUMB,
and others as ALWAYS-UP.  There are PRIME systems listed which do not
participate in GGP routing, do not forward packets, or do not issue ICMP
redirect messages.

Mike Brescia

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

BBN - gateway code supported by BBN.  There are 24 listed.

GGP - exchange GGP routing info with some BBN gateways. There are 3.

NR  - known to some BBN gateways as 'non-routing' (non-GGP) paths to
    some net(s).  Note: these are NOT pinged.  There are 8 listed, and
    in addition, there are NR gateways with addresses 10.0.0.25,
    10.1.0.77, and 10.2.0.78.

BBN GATEWAY : 1.0.0.11, 3.0.0.62 : BBN-PR-GATEWAY :: MOS : IP/GW,GW/PRIME :
BBN GATEWAY : 4.0.0.38, 48.0.0.4, 50.0.0.4 : NTARE-GATEWAY,NTA-GATEWAY,NDRE
BBN GATEWAY : 4.0.0.60, 32.3.0.42, 35.7.0.0, 128.16.0.0 : UCL-GATEWAY,GOONH
BBN GATEWAY : 4.0.0.76 : DFVLR-GATEWAY : LSI-11/23 : MOS : IP/GW,GW/PRIME :
    GATEWAY : 4.0.0.92 : FUCINO-IG : H-316 : SIMP : IP/GW :
BBN GATEWAY : 8.3.0.14, 192.1.2.1 : BBN-FIBER-GATEWAY,BBN-FIBER,FIBER : LSI
NR  GATEWAY : 10.3.0.2, 39.128.1.230 : SRINET-GATEWAY :: UNIX : IP/GW,GW/DU
NR  GATEWAY : 10.0.0.4, 192.5.12.21 : UTAH-GATEWAY : VAX-11/750 : UNIX : IP
    GATEWAY : 10.2.0.5, 3.2.0.5 : BBN-PTIP-GATEWAY,BBN-RCC : PLURIBUS :: IP
BBN GATEWAY : 10.5.0.5, 26.2.0.49 : BBN-MILNET-GWY,MILBBN,BBN-MILNET-GW : L
    GATEWAY : 10.3.0.10, 28.9.0.0 : LL-PSAT-IG,LL-11 ::: IP/GW,GW/DUMB :
    GATEWAY : 10.5.0.10, 28.18.0.0, 28.19.0.0 : LL-GW : PDP-11/44 : EPOS :
NR  GATEWAY : 10.1.0.11, 36.40.0.62 : STANFORD-GATEWAY : LSI-11/23 : MOS :
NR  GATEWAY : 10.2.0.14, 128.2.254.36 : CMU-GATEWAY : PDP-11/40 :: IP/GW,GW
GGP GATEWAY : 10.3.0.17, 128.4.0.1, 128.5.0.1, 128.8.0.1 : DCN-GATEWAY : LS
BBN GATEWAY : 10.1.0.20, 128.19.0.2, 4.0.0.24 : DCEC-GATEWAY,EDN-GATEWAY :
    GATEWAY : 10.5.0.20, 28.10.0.0 : DCEC-PSAT-IG ::: IP/GW,GW/ALWAYS-UP :
BBN GATEWAY : 10.7.0.20, 26.0.0.104 : DCEC-MILNET-GWY,MILDCEC,DCEC-MILNET-G
BBN GATEWAY : 10.2.0.22, 26.0.0.103 : ISI-MILNET-GWY,MILISI,ISI-MILNET-GW :
    GATEWAY : 10.3.0.22, 28.8.0.0 : ISI-PSAT-IG ::: IP/GW,GW/DUMB :
BBN GATEWAY : 10.2.0.25, 4.0.0.61 : CSS-GATEWAY : PDP-11/40 : MOS : IP/GW,G
BBN GATEWAY : 10.3.0.27, 128.9.0.81 : ISI-GATEWAY,ISI-GW : PDP-11/23 : MOS
BBN GATEWAY : 10.2.0.28, 26.0.0.106 : ARPA-MILNET-GWY,MILARPA,ARPA-MILNET-G
BBN GATEWAY : 10.2.0.37, 128.10.0.3 : PURDUE-CS-GW : PDP-11/34 : MOS : IP/G
BBN GATEWAY : 10.0.0.38, 9.0.0.11 : BRAGG-GWY1 : LSI-11/2 : MOS : IP/GW,GW/
BBN GATEWAY : 10.3.0.38 : NET-5-GATEWAY : LSI-11/2 : MOS : IP :
BBN GATEWAY : 10.1.0.49, 128.11.0.1, 192.1.2.3 : BBN-CGTWY,CGTWY,CRONUS : L
    GATEWAY : 10.5.0.49, 4.0.0.30 : CLARKSBURG-IG : C/30 : SIMP : IP/GW,GW/
BBN GATEWAY : 10.1.0.51, 128.21.0.11 : SRI-C3P0 : LSI-11/2 : MOS : IP/GW,GW
    GATEWAY : 10.1.3.51, 28.11.0.0 : SRI-PSAT-IG ::: IP/GW,GW/ALWAYS-UP :
BBN GATEWAY : 10.3.0.51, 45.0.0.11, 128.21.0.12 : SRI-R2D2 : LSI-11/2 : MOS
BBN GATEWAY : 10.4.0.51, 26.2.0.73 : SRI-MILNET-GWY,MILSRI,SRI-MILNET-GW :
NR  GATEWAY : 10.1.0.54, 192.5.7.2 : CIT-CS-GW : VAX-11/780 : UNIX : IP/GW,
BBN GATEWAY : 10.3.0.72, 8.3.0.8 : BBN-NET-GATEWAY,BBN-RCC-GATEWAY : LSI-11
GGP GATEWAY : 10.0.0.77, 18.10.0.4 : MIT-GW,MIT-GATEWAY : PDP-11 : MOS : IP
BBN GATEWAY : 10.2.0.80, 26.0.0.105 : SAC-MILNET-GWY,MILSAC,SAC-MILNET-GW :
BBN GATEWAY : 10.3.0.80, 47.0.0.11 : SAC-GATEWAY,SAC-GW,SAC-GWY1 : PDP-11/2
NR  GATEWAY : 10.3.0.91, 192.5.8.5 : UW-VLSI-GW : VAX-11/780 : UNIX : IP/GW
BBN GATEWAY : 10.0.0.94, 192.5.2.6 : WISC-GATEWAY : PDP-11/34 : MOS : IP/GW
    GATEWAY : 10.3.0.96, 192.5.36.5 : CORNELL-GW : VAX-11/780 : UNIX : IP/G
BBN GATEWAY : 14.0.0.10 : BBN-VAN-GW ::::
GGP GATEWAY : 25.6.0.0, 25.13.0.0, 35.6.0.0 : RSRE-GATEWAY :: EMMOS : IP/GW
    GATEWAY : 26.1.0.18, 28.12.0.0 : RADC-PSAT-IG : PLURIBUS :: IP/GW,GW/AL
    GATEWAY : 26.0.0.29, 192.5.22.2 : BRL-GATEWAY2 :: UNIX : IP/GW,GW/DUMB
NR  GATEWAY : 26.3.0.29, 192.5.21.5, 128.20.0.1, 192.5.25.2 : BRL-GATEWAY :
NR  GATEWAY : 26.0.0.58, 192.5.15.129 : NYU-GW : VAX-11/780 : UNIX : IP/GW,
    GATEWAY : 26.0.0.81, 192.5.27.0 : DTNSRDC-GW : VAX-11/750 : UNIX : IP/G
    GATEWAY : 26.3.0.81, 192.5.26.0 : NSRDCOA-GW : VAX-11/750 : UNIX : IP/G
    GATEWAY : 128.10.0.2, 14.0.0.1 : CSNET-PURDUE-GW : VAX-11/780 : UNIX :

[ Don't forget BRL-GATEWAY and BRL-GATEWAY2 !  -Mike ]

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

Date: Tue 13 Sep 83 12:47:03-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Only PRIME gateways should ping DUMB gateways
To: ROODE@SRI-NIC.ARPA
cc: tcp-ip@SRI-NIC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Roode's statement that PRIME gateways should know about all DUMB
gateways is laudable.  Many of us assumed it was reality.
Unfortunately, it isn't.  Were it to become reality (and be guaranteed
as such), it would make the pinging problem academic.  Every site could
be given its officially assigned two PRIME gateways and that would be
that.

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

Date: Tue 13 Sep 83 17:01:48-PDT
From: Mathis@SRI-KL.ARPA
Subject: Re: Core, GGP, and non-GGP gateways; a list
To: brescia@BBN-UNIX.ARPA
cc: tcp-ip@SRI-NIC.ARPA, Mathis@SRI-KL.ARPA

   The gateway list also needs to be trimmed of gateways that are essentally
useless for general internet routing purposes.  For example, I don't think
the various SIMP and PSAT gateways should be included since those gateways
are essentially for internal test use.  Is there a SATNET/WB NET position
on whether those gateways should be included if we assume that any gateway
not known to the BBN/GGP gateways should be pinged?
Jim

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

Date: 14 Sep 1983 12:10:53-EST
From: Christopher A Kent <cak@purdue>
Reply-to: cak@purdue
To: POSTEL@usc-isif
cc: tcp-ip@sri-nic
Subject: Re: Some Comments on Gateways & Procedures

I think it's great that all this stored up knowledge is finally making
it into the open. I have learned a lot about this by having to figure
it out (I have had some willing tutors, scattered across the internet)
in order to keep my users happy and keep my "worked-all-nets" certificate
up to date.

There is at least one additional type of gateway -- the gateway that
understands (some) GGP, reroutes packets, and speaks full ICMP, but
isn't one of the "core" gateways supported by BBN and participating
in the full GGP conversation. The gateway that I built for the BBN
VAX TCP is one of these; I believe that the standalone gateway at
CMU is also. The MIT C-Gateway may be as well.

Thus, the people that use "my" gateway at their site list it as both
DUMB and PRIME, depending on their intent. If an errant datagram makes
its way to one of these gateways, bound for a network to which the
gateway is not connected, it will send a redirect and route the
'gram appropriately, if it knows how (if it's in the NIC's table,
it probably knows how). So it's not a true stub gateway. It responds
to both GGP and ICMP Pings, so it's not a DUMB or ALWAYS-UP. But
it doesn't send or receive GGP routing updates, so it's not really
PRIME, either.

I have as many of the gateways listed with NIC installed in my tables
as possible; we don't ping gateways unless we're using them, and
don't in general seem to have too much trouble getting to networks
far and wide. If the core gateways would update their tables to know
about new stub gateways more quickly, I think we would be saved
an awful lot of grief.

Cheers,
chris

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

Date: 14 Sep 1983 1022-PDT
Subject: Re: Core, GGP, and non-GGP gateways; a list
From: Ian H. Merritt <MERRITT@usc-isib>
To: Mathis@SRI-KL.ARPA
cc: brescia@BBN-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA

I agree it is not a good idea to be pinging WBnet gateways.  Since these
are, at least for the moment, primarly used for experiments, often
including traffic measurements, pinging could distort the results.
Though the access to the internet could be disabled for most
experiments, the WBnet is not yet available for reliable or even
semi-reliable service, and should not really be known about by any
machines not directly participating in the experiments.

					Ian H. Merritt
					Wideband Communications Project
					USC/ISI

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

END OF TCP-IP DIGEST
********************

END OF DOCUMENT