From owner-freebsd-net@FreeBSD.ORG Wed Nov 14 07:32:10 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 6E4996D1 for ; Wed, 14 Nov 2012 07:32:10 +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 2C1FF8FC14 for ; Wed, 14 Nov 2012 07:32:09 +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 3Y1cpw70Mdz13Mp; Wed, 14 Nov 2012 07:32:08 +0000 (GMT) Message-ID: <50A348F8.1050805@rewt.org.uk> Date: Wed, 14 Nov 2012 07:32:08 +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: 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> In-Reply-To: <082A52DA-3C04-46B7-A0C6-2F1CD814C01C@chittenden.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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:32:10 -0000 On 14/11/2012 07:25, Sean Chittenden wrote: >>>>>> The check to drop ICMP replies to a source of 0.0.0.0/8 was added >>>>>> in r120958 as part of a fix for link local addresses. It was only >>>>>> applied to ICMP which is inconsistent as you've found out. >>>>>> >>>>>>> ?? Any thoughts as to why? It doesn't appear that the current behavior abides by RFC5735. >>>>>> Reading this section and RFC1122 it is not entirely clear to me >>>>>> what the allowed scope of 0.0.0.0/8 is. I do agree though that >>>>>> blocking it only in ICMP is not useful if it is allowed in the >>>>>> normal IP input path. >>>>>> >>>>>> Can you please check how other OS's (Linux, Windows) deal with it? >>>> >>>> 0/8 is not supposed to be used, as per the rfc. As such it doesn't work on most systems (Linux, network appliance vendors included) so this working *should* be a bug, IMO. >>> >>> Where does it say that it shouldn't be used? Which RFC & §? There are plenty of RFCs and I haven't exhaustively read things, so I reserve the right to be wrong & corrected, but I haven't seen anything that says, "do not use 0.0.0.0/8." 0.0.0.0/32, yes, that's a reserved and special IP address, but the remainder of the /8? It's a stretch to argue that it can't be used. >> >> There are several, including the one you referenced where it references the other addresses can only be used as a source address. It is vague but accepted that 0/8 isn't usable as anything other than that. > > Can you be more specific? I read "other addresses within 0.0.0.0/8 may be used to refer to specified hosts on this network" as an indication that use of 0/8 is intended to be supported. > >> 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.