Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!umd5!purdue!decwrl!labrea!agate!ucbvax!kinetics.UUCP!minshall
From: minshall@kinetics.UUCP (Greg Minshall)
Newsgroups: comp.protocols.tcp-ip
Subject: hosts and gateways and protocols
Message-ID: <8805161802.AA15658@mtxinu.UUCP>
Date: 16 May 88 17:55:57 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 44

This is a very nice and timely discussion for me, given where I am
in some product development cycle.

What my tendancy has been is to allow for the specification of a default
router (yes, just one).  If the router isn't specified, then we listen
for RIP broadcasts.  Now, I never know what is INSIDE a RIP packet.  However,
I choose a default router based on the largest RIP packet seen, and I stay
with that router for five minutes or so.  So, if I continue getting RIP
packets, then I keep following routers.

Whenever I receive a host or network ICMP redirect, I update my *HOST* route
(based on the destination IP address which comes along with the ICMP packet).
This host route lives for five minutes or so (maybe 20 minutes).  It then
times out, and we use the current default router to send to (the router
may then send back a redirect, which we will believe).

I am very sympathetic to almost all sides of this debate.  I strongly believe
that hosts should stay out of the routing game.  I strongly *wish* all
hosts had only one interface, but that isn't always desireable.

I also feel for those souls whose routers occasionally crash, and who would
like routes to switch automatically.  I don't believe that just because
you need this capability once per day that should exclude it from being
automated.

Right now, listening for RIP packets is, in many environments, the best way
to locate potential gateways.  There is no reason this needs to have a
separate process listening - consider these packets to be like ICMP packets.

As a design issue, I think that the ISO scheme seems very well thought out.
I want to be able to hear "I'm a router and I'm alive" packets at a fairly
high rate (at least once per minute).

I tend to lean towards unsolicited broadcasts (multicasts, whatever) from the
routers rather than a "query-response" scheme ("any routers out there?" "here
I am") for a few reasons.  First off, there are many more hosts than gateways,
so the unsolicited broadcasts should generate less (broadcast or multicast)
traffic.  Second, I'd rather not have to worry about how a uni-directional
UDP stream is supposed to decide that its packets aren't making it to the
other end of the wire.  Third, I'm not sure that every time TCP retransmits
a packet I want to have to revalidate the route.

Greg Minshall

Kinetics, Inc.		415-947-0998		ucbvax!mtxinu!kinetics!minshall