On Wed, 17 Mar 1999, Michael Kukat wrote:

> I often thought, it's to disable network root FS, but, examining the
> sources, there are also the following possibilities:
> 
> options        NFS_BOOT_BOOTP
> options        NFS_BOOT_DHCP
> 
> BOOTP if nicer 'cause of the netmask also supported (i hope, this works,
> my network is correctly Class-C with 192.168-addresses), BOOTPARAM makes
> trouble with often used 10.x.x.x networks with Class-C-netmask.

I have read this thing about the netmask in a lot of posts by now, and I
think it's time someone put this straight, so I'll try...

First of all. Any "normal" IP address is placed in one of three classes; 
A, B or C-class address. Looking at it binary, an A-class address starts
with a 0, a B-class address starts with 10, and a C-class with 110.

Easy so far.

Now, each IP address is divided into two parts; the network number and the
machine number. In an A-class address, the network number is eight bits,
and the machine number is 24 bits. A B-class address has sixteen bits for
each, and a C-class address has 24 bits for network and eight bits for
machine number.

Notice that nowhere has the term "netmask" come into this yet.

This is IP in it's original state, and everything should support it, no
matter what else. Broadcasts are normally an address is the machine number
bits all set to one, so the "classic" arpanet broadcast was
10.255.255.255, and any machine on network 10 should recogize that
broadcast address, no matter what.

Okay?

Enter subnetworks. The problem was/is that not many physical, real
networks normally have anything close to 65534 machines, not to mention
2^24-2, so it don't make much sense to have A-class or B-class networks.
To get them more useful, subnets were invented, in which an IP-address was
further divided. The subnet mask is a way of adding additional parts of
the host number to the network number within the appropriate class
network. Notice that from outside that network, the subnet don't enter
into it, that part is only recognized within the proper net.
Since the subnet mask is a mask, you can actually allocate any of the bits
to the subnet number, and those bits don't have to be contigous, even if
it now is recognized that it's a bad idea to not allocate them contigous.

Where does this leave us? Well, we now actually have two different network
numbers we might respond to. We have the original network number, which we
are a part of, it hasn't disappeared, and we also have "our" subnet. Both
of these have broadcast addresses, and we should actually respond to both.

I'd claim that any implementation that don't is buggy, unless some recent
RFC has gone and changed this.

So, software that use the standard approach to broadcasts is doing the
right thing, by the book.

The sad thing, now that I've written this, is that I don't have any
solution for the problem with buggy software, in this case the TCP7IP
implementation in NetBSD, I realize...

Sorry for the wasted bandwidth. :-)

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol