Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Nov 2012 23:06:04 -0800
From:      Sean Chittenden <sean@chittenden.org>
To:        Joe Holden <lists@rewt.org.uk>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, gnn@freebsd.org
Subject:   Re: 0.0.0.0/8 oddities...
Message-ID:  <7BE7E643-FB13-45DE-BA40-257B8ADFAA98@chittenden.org>
In-Reply-To: <50A32FE7.2010206@rewt.org.uk>
References:  <DC8A0D79-8DF3-472F-9B1A-76BF8577A03C@chittenden.org> <50A20359.9080906@networx.ch> <7C614093-6408-49C6-8515-F6C09183453B@chittenden.org> <50A32FE7.2010206@rewt.org.uk>

next in thread | previous 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 =A73 of RFC5735, it =
would appear that this network is valid:
>>>>=20
>>>> https://tools.ietf.org/html/rfc5735#section-3
>>>>=20
>>>>>   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.
>>> 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.
>>>=20
>>>> ?? 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.
>>>=20
>>> Can you please check how other OS's (Linux, Windows) deal with it?
>=20
> 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 & =A7? 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7BE7E643-FB13-45DE-BA40-257B8ADFAA98>