Path: utzoo!attcan!uunet!decwrl!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Help using ka9q to protect sources
Message-ID: <9010021500.AA10629@ftp.com>
Date: 2 Oct 90 15:00:05 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 21

The issue with reserving subnet bit values of all-zeroes and all-ones has
its roots in the concept of the "all subnets broadcast".  In other words,
if I have net 128.127.0.0 and 8 bits of subnet, the destination address
128.127.255.255 means "broadcast this packet on all subnets of 128.127".
A destination of 128.127.50.255 means "broadcast this only on subnet
128.127.50".

So why is zero magic, too?  At the time that the HRRFC was in the works, there
were still a *lot* of 4.2-based systems out there, and the group was more
than a little afraid of their propensity for broadcast storms (4bsd is also
the reason that the whole class A address space of 127.0.0.0 is reserved).

In the future, if IP multicast becomes wildely supported, the concept of
an "all subnets" broadcast will probably become obsolete (I don't know of
anything other than perhaps a few locally-written applications that actually
uses it in any case).  In the mean time, if you don't have 4.2-derived systems
around (even some SysVs and other non-Unix OSes like 0.0.0.0 as the broadcast
address), you can probably safely use the zero subnet.

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