From owner-freebsd-net@FreeBSD.ORG Tue Nov 13 08:22:55 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 024CA5F8 for ; Tue, 13 Nov 2012 08:22:54 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1158FC08 for ; Tue, 13 Nov 2012 08:22:53 +0000 (UTC) Received: (qmail 23372 invoked from network); 13 Nov 2012 09:57:07 -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 ; 13 Nov 2012 09:57:07 -0000 Message-ID: <50A20359.9080906@networx.ch> Date: Tue, 13 Nov 2012 09:22:49 +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: In-Reply-To: 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: Tue, 13 Nov 2012 08:22:55 -0000 On 13.11.2012 08:42, 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? You may also want to search for this question on NANOG, and if not found raise it there. -- Andre