Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Nov 2012 05:45:11 +0000
From:      Joe Holden <lists@rewt.org.uk>
To:        Sean Chittenden <sean@chittenden.org>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, gnn@freebsd.org
Subject:   Re: 0.0.0.0/8 oddities...
Message-ID:  <50A32FE7.2010206@rewt.org.uk>
In-Reply-To: <7C614093-6408-49C6-8515-F6C09183453B@chittenden.org>
References:  <DC8A0D79-8DF3-472F-9B1A-76BF8577A03C@chittenden.org> <50A20359.9080906@networx.ch> <7C614093-6408-49C6-8515-F6C09183453B@chittenden.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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?
> 
<snip>
> --
> 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)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A32FE7.2010206>