>Number:         5645
>Category:       standards
>Synopsis:       Requests to 0.0.0.0 are not being answered.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 23 23:05:00 1998
>Last-Modified:
>Originator:     Skeelo
>Organization:
	
>Release:        NetBSD-current 06/1998	<NetBSD-current source date>
>Environment:
	
System: NetBSD white-dwarf.dyn.ml.org 1.3F NetBSD 1.3F (GNOME) #10: Tue Jun 16 02:46:10 EDT 1998 root@white-dwarf:/usr/sup/current/src/sys/arch/mac68k/compile/GNOME mac68k


>Description:
Any request to 0.0.0.0 gets no response.

Log of comments from current-users follows:

Date: Tue, 23 Jun 1998 01:45:29 -0400 (EDT)
From: Skeelo <skeelo@white-dwarf.dyn.ml.org>
To: current-users@NetBSD.ORG
Cc: port-mac68k@NetBSD.ORG
Subject: 0.0.0.0 Weirdness?

First, sorry for the cross post. But I'm not sure where this should be.
I'm running a -current NetBSD/mac68k (33mhz '030 with 36MB RAM) and would
like to see this resolved.

Has anyone else noticed that requests to 0.0.0.0 don't connect anymore?
I'm not quite sure when this started for me but I first noticed it when my
nameserver wasn't answering requests. I had "nameserver 0.0.0.0" in my
/etc/resolv.conf, that was easy enough to fix but this is starting to bug
me. If this isn't something unique to my system (I doubt it's just me)
then I'll be happy to fill in a pr with what little information I have but
if someone more knowledgable wants to file one I'll be happy to let them
instead.

Thanks.

Date: Tue, 23 Jun 1998 03:37:53 -0700
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
To: Skeelo <skeelo@white-dwarf.dyn.ml.org>,
Cc: current-users@NetBSD.ORG,
    port-mac68k@NetBSD.ORG
Subject: Re: 0.0.0.0 Weirdness?


...try ping 0.0.0.0 on a multihomed host.  It's pretty clear that
-current is treating this as a broadcast address. And indeed,
in.c:in_broadcast() accepts INADDR_ANY as a broadcast.  It looks to me
like a violation of rfc1123 sec 3.3.6.  Oops.  Please send a PR.

And looking at tcpdump, -current is sending the packet out, but
unicasting it to the next-hop router (or is it just the default
route?)  Double Oops (assuming this was intended as a nonstanadard
broadcast address, per above).  Definitely send a PR.


If we do that at all, i think we have to make it configurable (via
sysctl) and rfc1123 says the option SHOULD default to using all-1s
broadcast.

(If it was up to me, i'd say its about time we gave up on 4.2BSD bugs.:->)

Date: Tue, 23 Jun 1998 10:59:43 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
To: current-users@NetBSD.ORG
Subject: Re: 0.0.0.0 Weirdness?

    [The following text is in the "iso-8859-1" character set]
    [Your display is set for the "US-ASCII" character set]
    [Some characters may be displayed incorrectly]

>How-To-Repeat:
	Try to use 0.0.0.0 as the target address.
	  Use 'nslookup www.netbsd.org 0.0.0.0' or 'telnet 0.0.0.0' and watch as the request times out.
	
>Fix:
	Unknown.
	
>Audit-Trail:
>Unformatted:
>> Has anyone else noticed that requests to 0.0.0.0 don't connect anymore?

> That doesn't sound like a problem.

...but it is, in that it's a deviation from long-standing BSD tradition.

> I don't think you can number a machine 0.

No, you can't.  But zero address bits mean "this" ("this network",
"this subnet", "this host"), so 0.0.0.0 means "this host, on this
subnet, on this network".  RFC-1122 3.2.1.3 says of this address

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

This seems to support the contention that it should "work".  However,
RFC-1122 3.2.1.3 also says that

            When a host sends any datagram, the IP source address MUST
            be one of its own IP addresses (but not a broadcast or
            multicast address).

This seems to imply that even if it is permitted to use 0.0.0.0 as a
destination address, replies can never be received from it, in which
case a TCP connection cannot be established (though there are some UDP
protocols which will work if replies don't come from the address they
"ought to").  However, that section goes on to say

            A host MUST silently discard an incoming datagram that is
            not destined for the host.  An incoming datagram is destined
            for the host if the datagram's destination address field is:

            (1)  (one of) the host's IP address(es); or

            (2)  an IP broadcast address valid for the connected
                 network; or

            (3)  the address for a multicast group of which the host is
                 a member on the incoming physical interface.

Thus, while it is permitted for a host to generate a packet from one of
its real addresses to 0.0.0.0, when it receives that packet (from
itself) it is required to silently discard it, thus again preventing
any communication from being established (even UDP-based
communication).

A standards-conformance point of view thus seems to imply that 0.0.0.0
must not "work".  As a pragmatic matter, though, I can't see any harm
in it, unless it complicates some code somewhere.  Furthermore,
standards like RFC-1122 define communication *between* machines;
provided such packets never leak onto the wire, provided they exist
only on a single host, it's entirely an internal matter and inter-host
standards like RFC-1122 have no jurisdiction.

If there is a standard that specifies the semantics of the various APIs
involved (does a standard exist for sockets?), it may have something to
say about the issue.  I'm not familiar with any such, though.

For my money, then, this is a quality-of-implementation issue.  I'm not
sure whether I consider "0.0.0.0 works" as good or bad, though. :)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Date: Tue, 23 Jun 1998 12:36:01 -0400 (EDT)
From: "Charles M. Hannum" <mycroft@mit.edu>
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc: current-users@NetBSD.ORG
Subject: Re: 0.0.0.0 Weirdness?


>>> Has anyone else noticed that requests to 0.0.0.0 don't connect anymore?
>
>> That doesn't sound like a problem.
>
> ...but it is, in that it's a deviation from long-standing BSD tradition.

It's more than just `tradition'.  This behaviour was specifically
advertised for many years.

I suspect that it broke with Thor's changes to hash local addresses.