Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: IP broadcasts using FTP's software
Message-ID: <9105311600.AA25736@ftp.com>
Date: 31 May 91 16:00:39 GMT
Sender: rwh@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 29


    I'm mostly concerned with how it works with routers when there are
    subnets in place.  The plain "128.66.255.255" did not work at a site
    with subnets were the broadcast had to cross a router.

Don't depend on IP broadcasts crossing routers.  Some routers can be
configured to forward "all subnets" (net.255.255) broadcasts through
all their interfaces, but not all of them.  Furthermore, the default
configuration won't forward them, because there is no mechanism to
avoid routing loops which echo the packet around and around a multiply-
connected net until the TTL runs out (and your hosts have been severely
stressed).

    And why is FTP doinking with the IP address we give in the send call?
    If I say I want it to go to "128.66.0.0", by golly, that's where they
    should send it!

Because of RFC 1122, pg 66 & 67.  "Hosts SHOULD use the Limited Broadcast
address to broadcast to a connected network."  Networks exist where adherence
to this would cause serious problems (read up on "broadcast storms" with old
0-style 4.2 systems configured with 'ipforwarding' enabled), so we had to
support a configurable IP broadcast address (see the '-b' switch on the
kernel's command line).  Thus, the configured value overrides whatever the
application asked for (which is likely to be compiled in and hard for the
user to change).

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901