HEDRICK@RED.RUTGERS.EDU.UUCP (06/03/86)
I have finally found a mechanism that seems to work for getting Suns to route automatically. It turns out that you can specify routing entries that will cause a host to treat destinations on that network as local. I.e. it will issue ARP's for them, just as if they were on the local Ethernet. The correct form is route add 0 <local-host-address> if you want to set this up as a default. It turns out that all of our diskless Sun 3's come up with such a default address automatically. We believe that this is due to a bug, but it is a fairly happy one, from my point of view. I have modified our gateway software to be able to handle a network where the hosts issue ARP's for everyone. The gateway responds to ARPs for hosts on the other side of the gateway. It also responds to ARPs for hosts on the other side of gateways that don't know about the convention (giving their Ethernet address, of course, not its own -- this is an ARP-level equivalent of an ICMP redirect). This strategy has a number of advantages from my point of view: - it requires no action on the part of the user, at least until Sun fixes their bug, if it is one. - the entry need not have wired-in knowledge of the gateway's address. If we change gateway configurations, this will continue to work. - if we have more than one gateway, and they talk to each other, we can take advantage of their redundancy, since we don't have specific routings built into the table. I'm sure the gateway committee will come up with a more elegant way to do things, but this looks like the best alternative to the problem I have been posing for some time. It involves no modification to Unix, does not depend upon hosts failing to validate ICMP redirects, etc. -------
MILLS@USC-ISID.ARPA.UUCP (06/03/86)
In response to the message sent 3 Jun 86 02:20:26 EDT from HEDRICK@RED.RUTGERS.EDU Charles, I think what you have accomplished is what has been viariously called the "ARP hack" or "promiscuous redirects." The technique has been proposed as a convenient way of transition to the subnet scheme proposed in RFC-950 and specified as a requirement in RFC-985. The technique has its own peculiar hazards and is viewed by some as outright dangerous. Nevertheless, it has proven useful in cases like yours (and ours). What this all means is that the Sun implementation could be considered a feature, not a bug. Dave -------
jsq@SALLY.UTEXAS.EDU (John Quarterman) (06/03/86)
Perhaps there should be an RFC on the ARP hack.
JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") (06/04/86)
RFC917 by Jeff Mogul talks about it in some length. Note that this approach is not advised as a general way to do routing in the host IP layer since the ARP layer was never designed to be a path for routing information interchange, and thus has lots of deficiencies when so used. A socket wrench makes a poor hammer. Jeff lists some in his memo; there are others, such as not being able to handle TOS routing, etc. Noel -------
HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) (06/04/86)
I'd rather use a socket wrench as a hammer than my bare hands. I'm eagerly awaiting the gateway group's proposals, and their implementation by all of the vendors supplying systems that we use. Until then, ARP-based routing is something that I can do that will work, and that does not abuse any standards too badly. I don't intend it to be for routing information interchange in the general sense. The gateways will use other protocols among themselves. What I need is a way to get information from the gateways to the hosts. I just reread the relevant section of 917, and in fact Mogul says that ARP-based subnetting is a reasonable strategy. His only criticism, other than the fact that it can only be implemented if you have broadcasts (which of course we do), is that there may be trouble recovering if a gateway goes down. In fact it is no more difficult to recover from gateway failure using ARP-based routing than using any other scheme. When a connection is about to time out, the system should attempt to recompute the route. It is just as easy to purge the ARP entry and issue another ARP as to purge the routing entry and do whatever you would normally do to find another routing at that level. In fact 4.2 does neither. But it does time out ARP entries, so eventually it will correct routings when ARP are being used to discover routes. Most alternative methods don't do even this well. I am assuming that our gateways will talk to each other, and arrange it so that the right gateway responds. That is, if one gateway goes down, and there is another route, the backup gateway will begin responding to ARP requests. In fact that gateway technology we are using (Stanford's) has this ability. Note that I have gone one step beyond the ARP-based subnetting described in RFC 917, in that I also use ARP's to identify routes to hosts outside our class B network. We currently have 3 different gateways to the outside world. One handles a single class C network. One handles a class B network and a class C network. The third is our Arpanet gateway, to which we send all other traffic. As the supercomputer network and other NSF-sponsored networking develop, we are likely to start moving traffic for certain other Universities from the Arpanet to one of the other networks. We do not want to have to change routing tables in every host when we make such a change. What is TOS routing? -------
jsq@SALLY.UTEXAS.EDU.UUCP (06/04/86)
Right. I had assumed RFC917 was completely superseded when RFC950 came out, but I see it still has quite a bit of useful information in it. The ARP hack has many deficiencies, as you point out, but many of us don't have much choice since we have systems to which we don't have the source and for which the vendor has not yet implemented subnets (e.g., TOPS-20, Silicon Graphics, Integrated Solutions, Bridge, Sun, VMS, Ridge, etc. ad nauseum). Perhaps the MIT ICMP host redirect method is the better interim solution. Does anyone have anything more to add on that than what's in RFC917?
narten@PURDUE.EDU ("Thomas Narten") (06/04/86)
>But [UNIX] does time out ARP entries, so eventually it will correct >routings when ARP are being used to discover routes. This is not always true. ARP entries that are not referenced for X minutes (20 for us) are deleted. This is not the same thing as saying IP to Ethernet mappings that aren't valid get deleted. If you continue to try to send to a host, the ARP entry continues to get referenced and will not time out at all. Hence, it is not clear that having paths through multiple gateways to the same destination will always be used the way one expects if the currently used gateway crashes. Thomas ----------
MILLS@USC-ISID.ARPA (06/04/86)
In response to the message sent 4 Jun 86 04:15:48 EDT from HEDRICK@RED.RUTGERS.EDU Charles, I'm not sure who you mean by the "gateway group." The old Gateway Algorithms and Data Structures (GADS) Task Force, which I chaired, has been dissolved and precipitated into the Internet Engineering (INENG) Task Force, Chaired by Mike Corrigan, and the Internet Architecture (INARC) Task FOrce, which I chair. THe INENG is concerned about relatively near-term (a couple of years) issues, while the INARC is looking further out. Both of these task forces are concerned about gateways, among many other issues. The NSF Network Technical Advisory Group (NTAG), which serves as advisor to NSF staff on network issues in general, including gateways for the explosively growing NSF Internet community, created an ad-hoc subcommittee to establish a first cut at Internet gateway requirements in general and the NSF community in particular. That subcommittee, also chaired by me, produced in close cooperation with the Internet Activities Board, chaired by Dave Clark, a working document that was published as RFC-985. You can see there is no single "gateway group," but a number of committees and task forces very much concerned with the issues being discussed here. The chairs mentioned above watch this list and others for developing issues and consider them carefully when constructing agendae and moderating meeting discussion. Nevertheless, the issues wandering around here on gateway routing, ARP, redirects and cranky Unix systems are incredibly complicated, easily misunderstood and highly flame-able. Speaking for myself and the above committees, we would very much like to harden the model proposed in RFC-985, especially in the technical details involved with multi-net cables, host-gateway routing, address resolution, redirects and so forth on Ethernets, TransLANs and similar technologies. If you have specific questions or comments you think unsuitable for this list, you are welcome to jiggle my chain or the others mentioned in RFC-985. Dave -------
mogul@SU-NAVAJO.ARPA (Jeff Mogul) (06/04/86)
I just reread the relevant section of 917, and in fact Mogul says that ARP-based subnetting is a reasonable strategy. Actually, about the nicest thing I said about it is that it is "somewhat unsatisfactory." I certainly did not intend this to be an excuse for IP vendors who aren't willing/able to get their acts together. Granted, this is less annoying than those hosts which spray broadcasts all over everything, or those that try to act as gateways when they aren't supposed to, but it really isn't that hard to get this right. I also (now) regret the term "ARP-based subnetting", for its implication that ARP is in any way central to the use of subnets. I don't have a perfect term, but something like "ARP-compatible subnetting" or "subnet-extended ARP" would be less misleading. I sure wish people who design widely-used IP implementations would test their bright ideas on the Internet community before shipping half a million workstations. -Jeff P.S.: Noel, you warned me.
JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") (06/05/86)
The so-called 'MIT ICMP' thing is not a change to the spec, merely one of way doing things of the ways allowed by the spec. There really isn't a lot to say beyond what's in RFC917. The 'ARP hack' is necessary for some machines since the per-host ICMP thing doesn't work if the source host doesn't realize that the destination is on another wire. Noel -------
matt@oddjob.UUCP.UUCP (06/11/86)
It turns out that you can specify routing entries that will cause a host to treat destinations on that network as local. I.e. it will issue ARP's for them, just as if they were on the local Ethernet. The correct form is route add 0 <local-host-address> if you want to set this up as a default. I tried "route add usan-net oddjob 0" some time ago, trying to access the USAN satellite net through our VitaLink box. This works to NCAR (where all hosts' addresses are on usan-net) if they do the corresponding operation on their end. The trouble comes when you want to specify that a host on the other net is a gateway to yet another net. The route-adding code insists that you can't do it. I then wrote a pseudo-interface driver which claims an interface address of "oddjob" (192.5.73.2) but a broadcast address of "usan-net" (192.17.4.0). This works OK (I'm still using it), but still has some drawbacks. One is that the other end (U of I at Urbana in this case) would have to put up a similar pseudo- interface on their gateway to usan-net before their networks and our networks are fully connected. Another is that broadcasts such as RIP packets sent to usan-net generate ICMP messages from other hosts on the local net here. I don't think any arrangement will really work satisfactorily if it has bridges connecting nets with different IP numbers. Matt Crawford
MILLS@USC-ISID.ARPA (06/11/86)
In response to the message sent Tue, 10 Jun 86 17:47:30 cdt from "Matt Crawford" <crawford@anl-mcs.arpa> Matt, USAN (192.17.4) is currently gatewayed to ARPANET via a fuzzball at U Michigan on an experimental basis. The fuzzball gateway is gimmicked with an incredible routing algorithm that provides connectivity for all the j-random networks babbling on the USAN channel, as well as many other networks that seem to be passing by from time to time. The gimmicks include "promiscuous" ARP, dynamic logical-address translation and multiple delay-based routing algorithms sharing the same cable. While the experiment is somewhat of a lashup at present, the experience gained seems to indicate that it would be practical to evolve a working standard for multiplexing broadcast channels with arbitrary routing plexes. Whether you want to do that on a performance basis may be another matter. The experience with showers of redirects and unreachables in this environment was what led to my suggestion a few days back on a standard filtering algorithm for Internet gateways. Hans-Werner Braun (hwb@gw-umich.edu) did most of the brain-punishing work in evolving the techniques and making the fuzzball gateway play on USAN. Dave -------