From owner-freebsd-net@FreeBSD.ORG Wed Nov 14 07:48:59 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 6A26C94F for ; Wed, 14 Nov 2012 07:48:59 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from mail01.lax1.stackjet.com (mon01.lax1.stackjet.com [174.136.104.178]) by mx1.freebsd.org (Postfix) with ESMTP id 476C08FC13 for ; Wed, 14 Nov 2012 07:48:59 +0000 (UTC) Received: from laptop-sean-wifi.local (173-228-12-182.dsl.dynamic.sonic.net [173.228.12.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sean@chittenden.org) by mail01.lax1.stackjet.com (Postfix) with ESMTPSA id B05F33E8D59; Tue, 13 Nov 2012 23:48:52 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 0.0.0.0/8 oddities... From: Sean Chittenden In-Reply-To: <50A348F8.1050805@rewt.org.uk> Date: Tue, 13 Nov 2012 23:48:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Joe Holden X-Mailer: Apple Mail (2.1499) Cc: "freebsd-net@freebsd.org" 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 07:48:59 -0000 >>> Regardless, why are you trying to do something that is unsupported = by pretty much every vendor/operator/os? >>=20 >> 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 >=20 > It's official registration is for "self identification", "this" = network doesn't mean the connected network. >=20 > 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=3D242956 Cheers (& thank you Andre for making the commit). -sc -- Sean Chittenden sean@chittenden.org