[ih] Internet History - broadcast addresses

[John Gilmore]

Karl Auerbach <karl at cavebear.com> wrote:
> Wasn't there also some disagreement over whether the IPv4 broadcast 
> address was 0.0.0.0 (BSD) or 255.255.255.255 (everybody else)?

Well, no; it was worse than that!  IP is still limping with the scars of
that mess.

4.2BSD defaulted to using the all-zeros node address of EACH SUBNET to
being the broadcast address.  The IP RFCs (later) ultimately decided to
use the all-ones node address of EACH SUBNET.  (In both cases, read
"network" for subnet, since subnetting hadn't been invented yet.)

You can see this in the first "standard" RFC for IP over Ethernet, RFC
894 by Charles Hornig of Symbolics:

  https://www.rfc-editor.org/rfc/rfc894.txt

  The broadcast Internet address (the address on that network with a
  host part of all binary ones) should be mapped to the broadcast
  Ethernet address (of all binary ones, FF-FF-FF-FF-FF-FF hex).

  ...

                                                           Unix 4.2bsd
  also uses a non-standard Internet broadcast address with a host part
  of all zeroes, this may also be changed in the future.)

I dug around in the great old tcp-ip mailing list's archives, and found
a few messages about this:

  http://securitydigest.org/tcp-ip/archive/1984/05

  Date:      Mon, 7 May 84 10:35 EDT
  From:      Charles Hornig <Hornig%SCRC-STONY-BROOK at SCRC-RIVERSIDE.ARPA>

  ...

     [RFC894]
	 Broadcast Address

	    The broadcast Internet address (the address on that network with a
	    host part of all binary ones) should be mapped to the broadcast
	    Ethernet address (of all binary ones, FF-FF-FF-FF-FF-FF hex).

      This is the first I've heard of this!  What's wrong with the 4.2
      convention?  [I've always made the (mostly correct) assumption
      that \no host on a network would be assigned address zero/.  This
      has the useful property that no additional context is necessary
      to differentiate a "network address" from "a particular host" on
      that network.  It's not hard to intuit that (for a broadcast
      network) sending \to the network/ is meaningful.]  There's also a
      practical justification--it's easier to check for a zero address
      than all ones (which is different for Class A, B, C networks).
      Sure you don't want to reconsider?

  I [Charles] picked all ones because that was the way other documents
  referred to it (I think IEN 212 is the right place).  I also think
  that all ones is better than all zeroes.  The zero value is likely to
  appear as a network name and reusing it as a broadcast address might
  lead to confusion between these ideas.

IEN 212 did indeed recommend reserving all-ones for broadcast, probably
as a mirror of the Ethernet FF:FF:FF:FF:FF:FF broadcast address:

  https://www.rfc-editor.org/ien/ien212.txt

  We propose to define the IP broadcast address to be the IP address in
  each class with all its local host part bits on. (E.G., A.255.255.255
  for class A, A.B.255.255 for class B, and A.B.C.255 for class C.)  In
  each case, the address would map to the local network broadcast
  address if broadcast addressing was supported.  On messages coming
  from other networks, the mapping would be done in the gateway.  If a
  network did not support broadcast addressing, an ICMP destination
  unreachable message would be returned.

But that IEN foolishly claimed that:

  The only "cost" of this mechanism is that it reserves one IP address
  from each class.

There were only three classes (A, B, and C), so it claimed to only
reserve 3 addresses.  But actually, it reserved one IP address from each
NETWORK NUMBER, of which there were tens of thousands.  And worse, it
reserved those IP addresses even in networks that do not use a LAN and
do not support broadcast addresses (by claiming that "Destination
Unreachable" would be the result of attempted communication).

Here is an excerpt from a 1986 discussion from TCP-IP that talks about
how to binary-patch subnets into your Suns that use 4.2BSD networking
stacks so they won't make broadcast storms based on different subnet
broadcast addresses:

  http://securitydigest.org/tcp-ip/archive/1986/08

  Date:      Mon, 11-Aug-86 09:08:38 EDT
  From:      HEDRICK at RED.RUTGERS.EDU (Charles Hedrick)
  To:        mod.protocols.tcp-ip
  Subject:   subnetting on Suns

  ...

  You need to decide what you want your broadcast address to be.  4.2 and
  the Sun kernel use the convention that the broadcast address uses a host
  number of 0.  The newest convention, implemented in 4.3, uses a host
  number of -1, i.e. 255. The standards were only changed recently, so
  must vendors have not caught up.  Consider our network, which is a class
  B network, 128.6.  On subnet 4, there are the following possible
  broadcast addresses:
    128.6.0.0	- used by 4.2
    128.6.4.0	- used by 4.2 if you install subnets
    128.6.255.255 - used by 4.3, I think
    128.6.4.255   - used by 4.3 with subnets turned on, I think
    255.255.255.255 - not used by any, but recognized by Sun and 4.3
  When you enable subnets, the subnet number becomes in effect part
  of your network number.  Thus the network number is 128.6.x, not
  just 128.6.  So the broadcast address ends up having the subnet
  number as part of it.

  Now, the problem is that the Suns are set up such that every machine
  on the network, including non-Suns, must agree on the broadcast
  address.  Otherwise there will be chaos and your network will be
  flooded with spurious packets, causing all of your machines to become
  unusable.    ...
  
This kind of packet storm problems led to banning the use of 0 as a
unicast host address in 1989 in Host Requirements, RFC 1122.

  https://www.rfc-editor.org/rfc/rfc1122.txt

  DISCUSSION: Silent discard of erroneous datagrams is generally
  intended to prevent "broadcast storms".

There's a whole section 3.3.6 in there that talks about broadcasting,
and other sections that require that the network layer pass "up" to the
IP layer an indication of whether the packet was broadcast or not, so
that network-layer broadcasts with unrecognized IP addresses can be
discarded rather than responded to.  It also recommends sending LAN
broadcasts to 255.255.255.255 rather than the actual reserved subnet
broadcast address, to improve interoperability.

So, as of today, TWO addresses per subnet are still reserved: 0 and
all-ones.  And with CIDR, we have millions of subnets, not just tens of
thousands, so we're wasting millions of addresses.

I suggest that, now that 4.2BSD is dead and gone, the protocols should
be revised to allow people to use the 0 address in each subnet for a
real unicast node, instead of reserving it.  And on non-LANs, we should
allow the all-ones address for a real node as well.  But that's about
the future, not about internet-history.

	John