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
s...@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?
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
