Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!hao!ames!ucbcad!ucbvax!ORVILLE.NAS.NASA.GOV!lekash
From: lekash@ORVILLE.NAS.NASA.GOV.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: On broadcasts, congestion and gong
Message-ID: <8710281927.AA11776@orville.nas.nasa.gov>
Date: Wed, 28-Oct-87 14:27:38 EST
Article-I.D.: orville.8710281927.AA11776
Posted: Wed Oct 28 14:27:38 1987
Date-Received: Sat, 31-Oct-87 10:43:45 EST
References: <8710280106.AA29957@okeeffe.Berkeley.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 56


> Please, check your facts before sending flames to mailing lists!
> 4.3BSD does NOT do IP forwarding on singly-homed hosts, although
> the ipforwarding variable is not cleared.  Only hosts with multiple
> hardware interfaces with IP addresses need to be configured consciously
> to avoid packet forwarding; such hosts need to be configured carefully
> in any case.  4.2's forwarding behavior was different, of course.
> Neither decision was random.

Sorry, I didn't feel very flame like.  Yes, I know BSD only
forwards on multiply homed hosts.  Perhaps random was a
poor random word choice, you may substitute carefully
considered.

Please do not consider what a said as a condemnation of 4.3BSD.
Of the operating systems we have here, it is the most reliable
and useful for my work.  I thank you for this, very much.

As you say, only hosts with multiple interfaces need to be carefully
configured in that fashion.  I interpret
this to mean gateways, since a host with two network
interfaces is only 1 line in /etc/rc.local more difficult than
a host with only one.   When the aforementioned decision was
made, you probably had not envisioned the kind of things that are
occuring at sites like here.  Every workstation comes with an
ethernet, and then has a hyperchannel added for performance to/from
a supercomputer.  So we have about 50 hosts that have multiple
interfaces, and many more on the way.

I believe that a system should have a minimum amount of default 
rope with which to hang oneself.    And so, since gateways need
the careful configuration, a default of not being a gateway seems
appropriate.  

I did in fact configure many of them correctly, but
after a time one turns such things over to others.  New distributions
come out of vendors, and someone just mangles their workstation, to
bring it up a rev.  Of course, the vendor has distributed it as they
got it, and the aforementioned careful configuration is wiped
out, despite written instructions that manage to disappear, and
aren't necessary, because 'it works'.  The brokenness is then
only found the next time I happen to spend a half hour
groveling with netwatch, one of the lesser exciting tasks.

I happen to have noted difficulties because of some degree of
perceived inconsistency.  There exists the options GATEWAY
kernel configuration parameter, which I would
think a useful mnemonic hook to hang enabling ipforwarding and sending
of redirects, which it wasn't last I looked.  It does control 
sending destination unreachable.  It is fairly common for people
to do the minimum necessary to configure something, thus will 
forget to set IPFORWARDING and IPSENDREDIRECTS, as well as setting
GATEWAY.  I will admit it is annoying to have to deal with possible
modes of screwing up, but it then means less work for me later on.

						john