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"

Reply via email to