From owner-freebsd-net@FreeBSD.ORG Tue Nov 13 07:49:41 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 2DA887C3 for ; Tue, 13 Nov 2012 07:49:41 +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 EC9468FC14 for ; Tue, 13 Nov 2012 07:49:40 +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 A661D3E8D40 for ; Mon, 12 Nov 2012 23:42:15 -0800 (PST) From: Sean Chittenden Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 0.0.0.0/8 oddities... Message-Id: Date: Mon, 12 Nov 2012 23:42:14 -0800 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) 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 07:49:41 -0000 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 =A73 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 =3D=3D 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.=20 ?? Any thoughts as to why? It doesn't appear that the current behavior = abides by RFC5735. -sc -- Sean Chittenden sean@chittenden.org