Date: Mon, 12 Nov 2012 23:42:14 -0800 From: Sean Chittenden <sean@chittenden.org> To: freebsd-net@freebsd.org Subject: 0.0.0.0/8 oddities... Message-ID: <DC8A0D79-8DF3-472F-9B1A-76BF8577A03C@chittenden.org>
next in thread | raw e-mail | index | archive | help
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. ?? Any thoughts as to why? It doesn't appear that the current behavior abides by RFC5735. -sc -- Sean Chittenden sean@chittenden.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DC8A0D79-8DF3-472F-9B1A-76BF8577A03C>