Date: Wed, 14 Nov 2012 07:21:25 +0000 From: Joe Holden <lists@rewt.org.uk> To: Sean Chittenden <sean@chittenden.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: 0.0.0.0/8 oddities... Message-ID: <50A34675.2020709@rewt.org.uk> In-Reply-To: <7BE7E643-FB13-45DE-BA40-257B8ADFAA98@chittenden.org> References: <DC8A0D79-8DF3-472F-9B1A-76BF8577A03C@chittenden.org> <50A20359.9080906@networx.ch> <7C614093-6408-49C6-8515-F6C09183453B@chittenden.org> <50A32FE7.2010206@rewt.org.uk> <7BE7E643-FB13-45DE-BA40-257B8ADFAA98@chittenden.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14/11/2012 07:06, 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? >> >> 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. > > Where does it say that it shouldn't be used? Which RFC & §? 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. > > -sc > > -- > Sean Chittenden > sean@chittenden.org 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. Regardless, why are you trying to do something that is unsupported by pretty much every vendor/operator/os?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A34675.2020709>