Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
I'll try again - maybe this time I'll be helpful.
Beginning with very early RFCs, all zeros was recommended to represent "this". So an IP address with an all-zeros host bits, such as this Class C, 192.168.1.0 would mean "this network", 192.168.1.
Hosts were not to be assigned all zeros as a host number so they wouldn't be confused with a (sub)network number. I.e., if you use 192.168.1.0 as either a source or destination IP it could have special meaning (just as the all ones host is used for broadcasts). As far as I can tell, little if anything used this special designation (except for some old Unix implementations that could use all zeros as the broadcast address).
However, with RFC 3021, allowing for /31s for P2P links, the all zeros and all one host bits denote hosts. This RFC does has some interesting things to say about how all zero host IPs should be treated:
(h) { , , 0 }
Subnetwork number. SHOULD NOT be used as a source address,
except when the originator is one of the endpoints of a point-
to-point link with a 31-bit mask. For other types of links, a
packet with such a destination SHOULD be silently discarded.
If these packets are not silently discarded, they MUST be treated
as IP broadcasts [RFC1812].
(f) { , , 0 }
Subnetwork number. SHOULD NOT be used as a source address,
except when the originator is one of the endpoints of a point-
to-point link with a 31-bit mask. For other types of links, a
packet with such a destination SHOULD be silently discarded.
If these packets are not silently discarded, they MUST be
treated as IP broadcasts.
(2) SHOULD silently discard on receipt (i.e., do not even deliver
to applications in the router) any packet addressed to 0.0.0.0 or
{ , 0 }. If these packets are not silently
discarded, they MUST be treated as IP broadcasts (see Section
[5.3.5]). There MAY be a configuration option to allow receipt of
these packets. This option SHOULD default to discarding them.
In a point-to-point link with a 31-bit mask, a packet addressed to
{ , 0 } corresponds to one of the endpoints of
such link, it MUST be treated as directed to the router on which
the address is applied.
(4) SHOULD NOT originate datagrams addressed to 0.0.0.0 or {
, 0 }. There MAY be a configuration option to
allow generation of these packets (instead of using the relevant
1s format broadcast). This option SHOULD default to not
generating them.
In a point-to-point link with a 31-bit mask, the configuration of
such a mask SHOULD allow for the generation of datagrams addressed
to { , 0 }.
With RFC 3021 (if I'm reading the above correctly), except for /31 P2P IPs, this shouldn't work, but the fact you've found it does, is likely due to most IP implementations not treating the all zeros host bits IP address as directed, above, but just as like another host IP. Again, if nothing really has used this special case, it simplifies the IP implementation.
In the above, technically, changing destination {, 0} as a MUST broadcast, should allow destination host to receive packet anyway.
Rule 4 is also interesting, as it assumes only /31 hosts can send to all zero hosts. This would be impossible to control if you don't know what the destination network-prefix is, and often only the destination truly knows.
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
I'll try again
