From owner-freebsd-net@FreeBSD.ORG Wed Nov 14 09:35:13 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 04538381 for ; Wed, 14 Nov 2012 09:35:13 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5324D8FC13 for ; Wed, 14 Nov 2012 09:35:11 +0000 (UTC) Received: (qmail 30213 invoked from network); 14 Nov 2012 11:09:13 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Nov 2012 11:09:13 -0000 Message-ID: <50A365C9.4010902@freebsd.org> Date: Wed, 14 Nov 2012 10:35:05 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Sean Chittenden 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Joe Holden 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:35:13 -0000 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