From owner-freebsd-net@FreeBSD.ORG Wed Nov 14 09:59:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1EE78AA; Wed, 14 Nov 2012 09:59:26 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (unknown [IPv6:2001:b70:201:2::22]) by mx1.freebsd.org (Postfix) with ESMTP id 6270A8FC16; Wed, 14 Nov 2012 09:59:25 +0000 (UTC) Received: from [172.16.11.21] (bella.stf.rewt.org.uk [91.208.177.62]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by abby.lhr1.as41113.net (Postfix) with ESMTPS id 3Y1h4r33bFz13N1; Wed, 14 Nov 2012 09:59:24 +0000 (GMT) Message-ID: <50A36B7B.50106@rewt.org.uk> Date: Wed, 14 Nov 2012 09:59:23 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: 0.0.0.0/8 oddities... References: <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> <50A365C9.4010902@freebsd.org> In-Reply-To: <50A365C9.4010902@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Sean Chittenden X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:59:27 -0000 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)