Date: Wed, 14 Nov 2012 09:59:23 +0000 From: Joe Holden <lists@rewt.org.uk> To: Andre Oppermann <andre@freebsd.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Sean Chittenden <sean@chittenden.org> Subject: Re: 0.0.0.0/8 oddities... Message-ID: <50A36B7B.50106@rewt.org.uk> In-Reply-To: <50A365C9.4010902@freebsd.org> References: <DC8A0D79-8DF3-472F-9B1A-76BF8577A03C@chittenden.org> <50A20359.9080906@networx.ch> <7C614093-6408-49C6-8515-F6C09183453B@chittenden.org> <50A32FE7.2010206@rewt.org.uk> <7BE7E643-FB13-45DE-BA40-257B8ADFAA98@chittenden.org> <50A34675.2020709@rewt.org.uk> <082A52DA-3C04-46B7-A0C6-2F1CD814C01C@chittenden.org> <50A348F8.1050805@rewt.org.uk> <C80C6D38-761B-469D-9650-9E54D5D870FE@chittenden.org> <50A365C9.4010902@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A36B7B.50106>