----MESSAGE-BEGIN---- <1983090107350000> Return-Path: Received: from ddn1 by SRI-NIC.ARPA with TCP; Thu 1 Sep 83 08:40:21-PDT Date: 1 September 1983 11:35 EDT From: dca-pgs @ DDN1 Subject: New names for TCP/IP Newsletter Mailing List To: tcp-ip @ sri-nic CC: dca-pgs @ DDN1, ddn-army @ DDN1, ddn-navy @ DDN1, ddn-usaf @ DDN1, ddn-dod @ DDN1, dcab615 @ DDN1 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090108520200> Return-Path: Received: from cvl by SRI-NIC.ARPA with TCP; Thu 1 Sep 83 09:55:15-PDT Date: 1 Sep 1983 12:52:02-EDT From: Louis A Mamakos Reply-to: louie@cvl To: tcp-ip@sri-nic.arpa Subject: Newsletter Mailing list ..could you please add 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090710482800> Return-Path: Received: from USC-ISID.ARPA by SRI-NIC with TCP; Wed 7 Sep 83 17:49:09-PDT 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 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090712030900> Return-Path: Received: from purdue by SRI-NIC with TCP; Wed 7 Sep 83 15:06:31-PDT Date: 7 Sep 1983 17:03:09-EST From: Christopher A Kent 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090712530100> Return-Path: Received: from RUTGERS.ARPA by SRI-NIC with TCP; Wed 7 Sep 83 13:54:34-PDT Date: 7 Sep 83 16:53:01 EDT From: Charles Hedrick 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? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090716170300> Return-Path: Received: from bbnccq by SRI-NIC with TCP; Wed 7 Sep 83 17:39:05-PDT Date: 7 Sep 1983 20:17:03 EDT (Wednesday) From: Mike Brescia Subject: Re: gateways, once again In-Reply-to: Your message of 7 Sep 1983 17:03:09-EST 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090717150100> Return-Path: Received: from RUTGERS.ARPA by SRI-NIC with TCP; Wed 7 Sep 83 18:16:31-PDT Date: 7 Sep 83 21:15:01 EDT From: Charles Hedrick 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 In-Reply-To: Message from "Mike Brescia " of 7 Sep 83 20:17:03 EDT 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090803010200> Return-Path: Received: from BBNG.ARPA by SRI-NIC with TCP; Thu 8 Sep 83 04:02:46-PDT Date: Thu 8 Sep 83 07:01:02-EDT From: Dan Tappan Subject: Re: gateways, once again To: HEDRICK@RUTGERS.ARPA cc: tcp-ip@SRI-NIC.ARPA, Tappan@BBNG.ARPA In-Reply-To: Your message of Wed 7 Sep 83 16:53:01-EDT 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090809060000> Return-Path: Received: from CMU-CS-PT by SRI-NIC with TCP; Thu 8 Sep 83 13:44:20-PDT Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 8 Sep 83 13:23:59 EDT Date: 8 Sep 83 1306 EDT (Thursday) From: don.provan@CMU-CS-A To: tcp-ip@SRI-NIC Subject: Re: gateways, once again In-Reply-To: "Dan Tappan's message of 8 Sep 83 06:01-EST" Message-Id: <08Sep83.130622.DP0N@CMU-CS-A> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090810544300> Return-Path: Received: from cvl by SRI-NIC with TCP; Thu 8 Sep 83 11:57:23-PDT Date: 8 Sep 1983 14:54:43-EDT From: Robert L Kirby Reply-to: kirby@cvl To: tcp-ip@sri-nic.arpa Subject: Joe Pallas has left CVL for Stanford Cc: postmaster@cvl 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090816451100> Mail-From: ROODE created at 8-Sep-83 23:45:11 Date: Thu 8 Sep 83 23:45:11-PDT From: David Roode Subject: Re: my conclusions from the discussion To: HEDRICK@RUTGERS, tcp-ip@SRI-NIC In-Reply-To: Message from "Charles Hedrick " of Fri 9 Sep 83 02:06:47-PDT Location: EJ286 Phone: (415) 859-2774 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090819000000> Return-Path: Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 10 Sep 83 15:09:15 PDT Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 9 Sep 83 21:36 EDT Sender: Mike Muuss From: TCP-IP@brl To: TCP-IP@brl Date: 9 Sep 1983 00:00 EST 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 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 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 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 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 Subject: Re: TCP/IP for VMS To: TCP-IP-Digest Cc: Chris Kent 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983090822064700> Return-Path: Received: from RUTGERS.ARPA by SRI-NIC with TCP; Thu 8 Sep 83 23:08:49-PDT Date: 9 Sep 83 02:06:47 EDT From: Charles Hedrick 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091112251500> Return-Path: Received: from USC-ISIF.ARPA by SRI-NIC with TCP; Sun 11 Sep 83 19:32:50-PDT 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 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091209324100> Return-Path: Received: from USC-ISIF.ARPA by SRI-NIC with TCP; Mon 12 Sep 83 16:37:24-PDT 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091209522200> Return-Path: Received: from USC-ISIF.ARPA by SRI-NIC with TCP; Mon 12 Sep 83 16:58:49-PDT 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091211453500> Return-Path: Received: from USC-ISIF.ARPA by SRI-NIC with TCP; Mon 12 Sep 83 20:51:22-PDT 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091214360300> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC with TCP; Mon 12 Sep 83 21:36:28-PDT Date: Mon 12 Sep 83 21:36:03-PDT From: Mark Crispin 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091215173400> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC with TCP; Mon 12 Sep 83 22:17:33-PDT Date: Mon 12 Sep 83 22:17:34-PDT From: Mark Crispin 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... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091215362400> Mail-From: ROODE created at 12-Sep-83 22:36:24 Date: Mon 12 Sep 83 22:36:24-PDT From: David Roode 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091219000000> Return-Path: Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 13 Sep 83 00:38:41 PDT Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 13 Sep 83 0:18 EDT Sender: Mike Muuss From: TCP-IP@brl To: TCP-IP@brl Date: 13 Sep 1983 00:00 EST 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 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 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 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 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 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 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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091219121800> Return-Path: Received: from SRI-KL.ARPA by SRI-NIC with TCP; Tue 13 Sep 83 02:21:13-PDT 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 In-Reply-To: Message from "Mark Crispin " of Tue 13 Sep 83 01:33:36-PDT 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091223583600> Return-Path: Received: from RUTGERS.ARPA by SRI-NIC with TCP; Tue 13 Sep 83 01:01:07-PDT Date: 13 Sep 83 03:58:36 EDT From: Charles Hedrick Subject: Re: Only PRIME gateways should ping DUMB gateways To: ROODE@SRI-NIC.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "David Roode " of 13 Sep 83 01:36:24 EDT 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091303215900> Return-Path: Received: from USC-ISIF.ARPA by SRI-NIC with TCP; Tue 13 Sep 83 10:22:54-PDT 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091305470300> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC with TCP; Tue 13 Sep 83 12:59:07-PDT Date: Tue 13 Sep 83 12:47:03-PDT From: Mark Crispin Subject: Re: Only PRIME gateways should ping DUMB gateways To: ROODE@SRI-NIC.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "David Roode " of Tue 13 Sep 83 00:23:24-PDT 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091310014800> Return-Path: Received: from SRI-KL.ARPA by SRI-NIC with TCP; Tue 13 Sep 83 17:05:52-PDT 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 In-Reply-To: Message from "Mike Brescia " of Tue 13 Sep 83 17:28:08-PDT 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091313280800> Return-Path: Received: from bbnccq by SRI-NIC with TCP; Tue 13 Sep 83 14:31:33-PDT Date: 13 Sep 1983 17:28:08 EDT (Tuesday) From: Mike Brescia Subject: Core, GGP, and non-GGP gateways; a list To: tcp-ip@nic Cc: brescia@BBN-UNIX Following gateway lines are from [nic]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 : ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091322444300> Return-Path: Received: from BRL-VGR by SRI-NIC with TCP; Wed 14 Sep 83 00:18:03-PDT Date: Wed, 14 Sep 83 2:44:43 EDT From: Mike Muuss To: Mike Brescia 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091403220000> Return-Path: Received: from USC-ISIB.ARPA by SRI-NIC with TCP; Wed 14 Sep 83 10:25:25-PDT Date: 14 Sep 1983 1022-PDT Subject: Re: Core, GGP, and non-GGP gateways; a list From: Ian H. Merritt To: Mathis@SRI-KL.ARPA cc: brescia@BBN-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Your message of Tue 13 Sep 83 17:01:48-PDT 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091407105300> Return-Path: Received: from purdue by SRI-NIC with TCP; Wed 14 Sep 83 10:17:05-PDT Date: 14 Sep 1983 12:10:53-EST From: Christopher A Kent Reply-to: cak@purdue To: POSTEL@USC-ISIF cc: tcp-ip@SRI-NIC Subject: Re: Some Comments on Gateways & Procedures In-reply-to: Your message of 13 Sep 1983 0033-EST (Tuesday). Message-ID: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983091412515300> Mail-From: ROODE created at 14-Sep-83 19:51:53 Date: Wed 14 Sep 83 19:51:53-PDT From: David Roode Subject: Re: New names for TCP/IP Newsletter Mailing List 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 In-Reply-To: Message from "dca-pgs @ DDN1" of Thu 1 Sep 83 11:35:00-PDT Location: EJ286 Phone: (415) 859-2774 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 . ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983092119000000> Return-Path: Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 22 Sep 83 13:27:30 PDT Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 22 Sep 83 8:43 EDT Sender: Mike Muuss From: TCP-IP@brl To: TCP-IP@brl Date: 22 Sep 1983 00:00 EST 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 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 ------------------------------ Date: 21 Sep 1983 20:19:11-PDT From: John L. Romkey 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 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 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 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 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 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 Subject: Core, GGP, and non-GGP gateways; a list To: tcp-ip@nic Cc: brescia@bbn-unix Following gateway lines are from [nic]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 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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [651%40brl-bmd.UUCP] <1983092205051400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: TCP-IP%brl@brl-bmd.UUCP (TCP-IP@brl) Newsgroups: fa.tcp-ip Subject: TCP-IP Digest, Vol 2 #17 Message-ID: <651@brl-bmd.UUCP> Date: Thu, 22-Sep-83 09:05:14 EDT Article-I.D.: brl-bmd.651 Posted: Thu Sep 22 09:05:14 1983 Date-Received: Fri, 23-Sep-83 21:25:14 EDT Lines: 671 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 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 ------------------------------ Date: 21 Sep 1983 20:19:11-PDT From: John L. Romkey 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 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 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 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 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 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 Subject: Core, GGP, and non-GGP gateways; a list To: tcp-ip@nic Cc: brescia@bbn-unix Following gateway lines are from [nic]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 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 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 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 ******************** ----MESSAGE-END----