From owner-freebsd-net@FreeBSD.ORG Wed Nov 14 07:25:21 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 AD2F95BC for ; Wed, 14 Nov 2012 07:25:21 +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 889EC8FC16 for ; Wed, 14 Nov 2012 07:25:21 +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 495B83E8D42; Tue, 13 Nov 2012 23:25:21 -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: <50A34675.2020709@rewt.org.uk> Date: Tue, 13 Nov 2012 23:25:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <082A52DA-3C04-46B7-A0C6-2F1CD814C01C@chittenden.org> 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> 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:25:21 -0000 >>>>> 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. >>>>>=20 >>>>>> ?? 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. >>>>>=20 >>>>> Can you please check how other OS's (Linux, Windows) deal with it? >>>=20 >>> 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. >>=20 >> Where does it say that it shouldn't be used? Which RFC & =A7? 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. >=20 > 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 -- Sean Chittenden sean@chittenden.org