On 13.11.2012 08:42, 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?
You may also want to search for this question on NANOG, and if not
found raise it there.
--
Andre
_______________________________________________
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"
