0.0.0.0/8 oddities...

[Joe Holden]

On 14/11/2012 09:35, Andre Oppermann wrote:
> On 14.11.2012 08:48, Sean Chittenden wrote:
>>>>> Regardless, why are you trying to do something that is unsupported
>>>>> by pretty much every vendor/operator/os?
>>>>
>>>> Status quo is fine and dandy if it's rational, backed up with a
>>>> justification and can be understood, but I'm not seeing anything
>>>> that suggests there's a good reason which indicates 0/8 shouldn't be
>>>> used or supported. -sc
>>>
>>> It's official registration is for "self identification", "this"
>>> network doesn't mean the connected network.
>>>
>>> All in all, even allowing an address in 0/8 to be configured is a bug
>>> based on both a) the various RFCs and intended use and b) that's how
>>> everyone else accepts that it should work anyway, so RFC is
>>> irrelevant in that case.
>>
>> I think that's incorrect. 127/8 is used for hosts local to a physical
>> server and 0/8 was intended for hosts "local to a network." In my
>> definition, "this network" is data center-local, however there's
>> nothing preventing that IP address range from being rack-local either,
>> etc.  0.0.0.0/32 is a shortcut for saying "me on this network," which
>> makes sense in the context of the wording in RFC 5735. Again, section
>> 3 paragraph 1:
>>
>> 0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
>>     network.  Address 0.0.0.0/32 may be used as a source address for this
>>     host on this network; other addresses within 0.0.0.0/8 may be used to
>>     refer to specified hosts on this network ([RFC1122], Section
>> 3.2.1.3).
>>
>> In environments where DNS is an extra service that requires
>> justification and would be an additional service that has to be
>> secured, exclusive use of well known IP addresses is both convenient
>> and useful, and the 0/8 network seems to have been defined for exactly
>> this purpose. I admit the address range isn't in wide use atm, but I
>> don't see a reason for it to not be.
>>
>> The fix Andre made appears to be correct, and IMO, should be merged in
>> to -head and MFC'ed.
>>
>> http://www.secnetix.de/~olli/FreeBSD/svnews/index.py?r=242956
>
> I agree, but I want to check how Linux and Windows behave first.
>
Andre,

On Linux it correctly returns invalid argument, on Winsock its 
explicitly invalid[1], on every network vendor I have tested it on, it 
is invalid.

Enabling this not only breaks compatibility with *everything* else, but 
also hasn't been tested and the ramifications on applications hasn't 
been checked, either.

Suggest user use an appropriate range from one of the 10 listed as 
reserved/special and retain the same behaviour as all the other platforms.

[1] 
http://msdn.microsoft.com/en-gb/library/windows/desktop/ms738586(v=vs.85).aspx 
(MS has the closest to "proper" behaviour IMO, Linux also behaves in a 
similar fashion however doesn't prevent the user from adding a 0/8 
address to an interface, it just doesn't work)