From owner-freebsd-net@FreeBSD.ORG Wed Nov 14 05:45: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 94803FCE; Wed, 14 Nov 2012 05:45:21 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE0C8FC0C; Wed, 14 Nov 2012 05:45:20 +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 3Y1ZRY1jQDz13Mp; Wed, 14 Nov 2012 05:45:13 +0000 (GMT) Message-ID: <50A32FE7.2010206@rewt.org.uk> Date: Wed, 14 Nov 2012 05:45:11 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) 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> In-Reply-To: <7C614093-6408-49C6-8515-F6C09183453B@chittenden.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" , gnn@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 05:45:21 -0000 Sean Chittenden wrote: >>> Hello. I ran in to an interesting situation in what appears to be an exotic situation. Specifically, after reviewing RFC5735 again and searching for a datacenter-local or rack-local IP range (i.e trying to provide services that are guaranteed to be provided in the same rack as the server), I settled on the 0.0.0.0/8 network. Per §3 of RFC5735, it would appear that this network is valid: >>> >>> https://tools.ietf.org/html/rfc5735#section-3 >>> >>>> 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). >>> And this works as expected, with regards to TCP services. But ICMP? Not so much. Is there a reason that ICMP would fail, but TCP (e.g. ssh) works? For example, I pulled 0.42.123.10 and 0.42.123.20 as IP addresses to use for NTP servers, but much to my surprise, I could ssh between the hosts, but I couldn't ping. Is this intentional? I understand that 0.0.0.0/32 == INADDR_ANY for source addresses, but it doesn't appear that there should be a restriction of inbound echoreq packets. According to tcpdump(1), the host is receiving echoreq packets, however no echorep packets are generated. As a work around, I threw things in to a more traditional RFC1918 network and things immediately worked for both SSH and ICMP. >> 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? > > -- > Sean Chittenden > seanc@FreeBSD.org 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. If you want address space there is plenty in RFC1918, or if you can't use that (shoot whoever did the addressing), there are others you could use (eg the new CGN space)