Date: Wed, 14 Nov 2012 10:15:13 +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: <50A36F31.3010706@rewt.org.uk> In-Reply-To: <50A36B7B.50106@rewt.org.uk> 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> <50A36B7B.50106@rewt.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14/11/2012 09:59, Joe Holden wrote: > 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) The other thing to note (which is the whole reason for this thread in the first place) is the incorrect handling of 0.0.0.0 by the stack, trying to end traffic to 0.0.0.0 should *not* end up with traffic going to the default route. At best it should return an error or at least be an alias to 127.0.0.1, like Linux.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A36F31.3010706>