RAF@CU.NIH.GOV (Roger Fajman) (02/17/90)
> The original PCIP package supported configuration of one default IP router, > and a local table of other routers built up via ICMP redirect messages. > This is what PC/TCP does at the moment, and I assume that most, if not all > of the other PCIP descendants do the same. It's a pain too, if you have multiple routers on your LAN. There's no way to configure things so that if one router goes out you will use another automatically. The upcoming Gateway Discovery protocol should be the ultimate solution to this, but in the meantime it would be helpful if PC/TCP were able to listen to RIP broadcasts for a default route only. Configuring multiple default routes would also be useful, but requires changing everyone's configuration if you add another router.
jbvb@VAX.FTP.COM (James Van Bokkelen) (02/17/90)
From: Roger Fajman <RAF@cu.nih.gov> Date: Fri, 16 Feb 90 12:41:35 EST .... The upcoming Gateway Discovery protocol should be the ultimate solution to this, but in the meantime it would be helpful if PC/TCP were able to listen to RIP broadcasts for a default route only. Configuring multiple default routes would also be useful, but requires changing everyone's configuration if you add another router. When the group working on the Host Requirements RFC discussed eavesdropping routing protocols, I was on the side that said "SHOULD NOT". I am keeping track of the GW Discovery effort, and given the most recent draft of the proposal, it should be simple to add. Multiple routers in the configuration should be in the next major release of PC/TCP in any case, and in the present version you can use BOOTP (via the RFC 1048 extensions) to set the single default router we presently support. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
RAF@CU.NIH.GOV (Roger Fajman) (02/17/90)
> When the group working on the Host Requirements RFC discussed > eavesdropping routing protocols, I was on the side that said "SHOULD > NOT". I am keeping track of the GW Discovery effort, and given the > most recent draft of the proposal, it should be simple to add. > Multiple routers in the configuration should be in the next major > release of PC/TCP in any case, and in the present version you can use > BOOTP (via the RFC 1048 extensions) to set the single default router > we presently support. > > James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 > FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 At the Interop 89 seesion on the Host Requirements RFCs, the question of eavesdropping on RIP for the sole purpose of obtaining a default route was raised. There seemed to be little objection from the panel to that. I don't specifically remember what you said though. The Gateway Discovery Protocol group does seem to be coming along. But they have defered the issue of dead gateway detection. Thus my problem of having a router go out of service doesn't seem to be dealt with. BOOTP is definitely worth looking at. Are you providing a server or must it be on a Unix machine? But BOOTP doesn't deal well with dead routers either. How do you plan to make use of multiple default routers?
jqj@rt-jqj.Stanford.EDU (JQ Johnson) (02/17/90)
Roger Fajman suggests that PC/TCP should be "able to listen to RIP broadcasts for a default route only." There is a potential for religious wars here, but let me take the opposite side: I would argue that RIP should be stamped out as fast as possible, and hence that anything that encourages it, e.g. such a change, is a bad idea for the Internet as a whole. Note that the Hosts Requirements RFCs are clear on this point: hosts should not snoop on IGP traffic. Roger is right, of course, that the Gateway Discovery Protocol, when finally adopted and if widele implemented, would solve the problem. JQ Johnson voice: 415-723-3078 Manager, Special Projects Internet: jqj@jessica.stanford.edu Networking and Communications Systems Pine Hall Rm 125-A Stanford University Stanford, CA 94305-4122
jbvb@VAX.FTP.COM (James Van Bokkelen) (02/17/90)
We weren't arguing about it on the panel, but there had been various opinions expressed during the e-mail discussion which actually put the RFC together. At one point, RIP eavesdropping was a SHOULD NOT, but an early effort at a gateway discovery/dead gateway detection protocol definition stalled, and those who wanted it to be a MAY made some headway. The actual text of RFC 1122 mentions it, as "...commonly used, but not recommended". We ship a BOOTP client for DOS, and we provide the CMU freeware BOOTP server for 4bsd Unix on one of our freeware diskettes. The way it would be useful is to change the default in the BOOTP server when a gateway is scheduled for maintenance, or the configuration changes. It doesn't help with transient failures. What we plan to do with multiple default routers is more or less as RFC 1122 outlines: fail-over on advice from other protocols (pp 52,53). James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
romkey@asylum.sf.ca.us (John Romkey) (02/17/90)
My personal feeling is that hosts eavesdropping on routing protocols is a very bad thing. It should be possible to change the routing substrate of the Internet without having to update all the host software as well (updating the routing software is pain enough, isn't it?). Which routing protocol do you eavesdrop on? RIP? OSPF? cisco's IGRP? Suppose I come along an introduce my Whizzy Turbo Router Plus, with proprietary routing protocols that give you great routing, and you install them all over your network - then your host software, in order to be able to route, has to know my proprietary routing protocols... I think the routing substrate ought to be as much of a black box to the hosts as is possible, with communication between the hosts and routers happening in a formalized way, say via a protocol. Eavesdropping is leaving yourself open for a lot of problems in the future. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com In the kingdom of the blind, the one-eyed are kings.
RAF@CU.NIH.GOV (Roger Fajman) (02/17/90)
> I think the routing substrate ought to be as much of a black box to > the hosts as is possible, with communication between the hosts and > routers happening in a formalized way, say via a protocol. > Eavesdropping is leaving yourself open for a lot of problems in the > future. I agree with this, but don't know how to explain to people that they can't do their work because a router is down and the elegant solution to the problem is still under construction. RIP is a special case, because there are already a lot of hosts that understand it and it's fairly easy to put just a default route out onto a network. I don't suggest eavesdropping on any other protocol. And it's really just a temporary expedient until gateway discovery and dead router discovery are implemented. As far as I've heard, a protocol for dead router discovery is not even under discussion yet. So it's going to be a long while before this problem is solved the right way.
nelson@sun.soe.clarkson.edu (Russ Nelson) (02/18/90)
In article <9002170000.AA23013@alw.nih.gov> RAF@CU.NIH.GOV (Roger Fajman) writes:
[Listen to RIP to discover router changes]
Version 0 of the "Discover Gateway" protocol could be implemented by
listening to RIP. I would guess that updating it to version 1 [when
the RFC is written] would be no more painful than updating from POP2
to POP3.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems