Re: Support for 240/4 and 0/8 addresses in NetBSD

[Seth David Schoen <schoen%loyalty.org@localhost>]

Taylor R Campbell writes:

> I think it's best to address the 240/4, 0/8, and 127/8 questions
> separately, because they pose very different types of risks: both 0/8
> and 127/8 have had semantics imbued on them by standards for years,
> some of which are security-critical like applications relying on 127/8
> packets never leaving the host.  In contrast, 240/4 has just been
> reserved, from what I understand, and nobody has ever come up with a
> special-purpose use for it.

Hi Taylor,

I think this is potentially true for 127/8 (although I don't know an
example of an application that intentionally uses a loopback address
outside of 127.0.0.0/16, I can see where, if such an application
exists, changing the semantics of 127/8 would cause it to behave in a
way that the developer didn't intend).  But I'm not sure what you mean
by semantics imbued on 0/8 here.  We've looked around a lot and not
found very much in that category.

Most famously, 0/8 was somehow supposed to mean "this network" but the
details of what that might mean (other than for the "ICMP Information
Request or Information Reply Message", p. 17 of RFC 792) were never
fleshed out anywhere or -- as far as I know -- implemented anywhere.
RFC 1122 says that a 0/8 address means

                 Specified host on this network.  It MUST NOT be sent,
                 except as a source address as part of an initialization
                 procedure by which the host learns its full IP address.

and then right in the same RFC says about the ICMP autoconfiguration
mechanism

         3.2.2.7  Information Request/Reply: RFC-792

            A host SHOULD NOT implement these messages.

            DISCUSSION:
                 The Information Request/Reply pair was intended to
                 support self-configuring systems such as diskless
                 workstations, to allow them to discover their IP
                 network numbers at boot time.  However, the RARP and
                 BOOTP protocols provide better mechanisms for a host to
                 discover its own IP address.

To add to this "however", RARP and BOOTP _don't use_ 0/8 addresses,
except for BOOTP sometimes using 0.0.0.0/32 as a source address.

Our conclusion has been that sometime between 1981 and 1989 it became
widely understood that 0/8 (except 0.0.0.0) was not being used for
anything at all, and that this was actually formalized in RFC 1122
(the only mechanism that RFC 1122 permits 0/8 to be used for is also a
mechanism that it says SHOULD NOT be implemented!).

We've found isolated examples where 0/8 addresses are in some sense
"used" for other purposes, but not for numbering hosts or routing packets
to them.